> The thing is, while the odd application crash due to memory exhaustion probably doesn’t bother some, it certainly bothers me. Do we really trust that applications will reliably save necessary state at all times prior to crashing due to a malloc failure? Are we really ok with important system processes occasionally dying, with system functionality accordingly affected? Wouldn’t it be better if this didn’t happen?<p>With virtual memory and paging, it's really up to the user what's too taxing on their system. And it's not an either-or, I greatly value an application that reliably saves its state consistently and often. Sublime Text is fantastic, I don't even have to press Save and can just pull the plug on the machine. This mitigates the allocation failure case as well as so many other failures.
I had a tiny business web site running a few 100 maybe 1000 http requests per minute, either static or doing minimal php/mysql work. So I hired a cloud machine of 512MB because shoestring budget. Resized a few memory pools.<p>It worked great, until the mysql dataset grew enough. There was a backup job running 7z and pulling the compressed DB to a storage machine. It turns out 7z crashed because of the OOM killer.<p>The http service itself just kept going on, OOM or not. Presumably because backup ran at 3AM and almost nobody was using it at that time.
The most annoying thing that apps do (even freaking vectors in c++) is that they do not return the memory to the system after they are done with a big task. Rather they will keep the memory just in case in the future they need it again.<p>No the unused memory is not yours to manage. Return it to the OS.
One reason for overcommit is because of COW.<p>For example, you fork() then exec() from a process using 16GB of memory: without overcommit, you briefly need 32GB of memory.