Re: holywar: malloc() vs. OOM

[Rich Felker <dalias@aerifal.cx>]

On Mon, Jul 25, 2011 at 09:43:43PM +0400, Vasiliy Kulikov wrote:
> Rich,
> 
> On Sun, Jul 24, 2011 at 18:19 -0400, Rich Felker wrote:
> > Any system without this guarantee is a TOY, nothing more. I'm aware
> > that the default sucks,
> 
> I don't think the default sucks, it is just targeted to other programs.

I disagree. I think the default discourages writing safe, robust
applications (people always say "Why should I check the result of
malloc? It will return success then crash later anyway because of
overcommit.") and encourages writing broken hackware that depends on
the availability of overcommit.

> Think about Java/Python programs, which request hundreds megabytes, but
> using only tens of them.

This is not a valid way to write applications. It's basically the same
as the classic joke about Windows 95 containing:

    if (rand()%1000==42) bsod();

I'm also a bit unsure how a Java or Python program would allocate
hundreds of megs but leave them completely untouched. Usually HLL's
dirty memory as soon as they allocate it with initialization, object
construction, etc. so I'm doubtful your example has anything to do
with the real world...

> Also daemons with fork() model being able to
> handle hundreds/thousands connections actively using COW would not be
> able to fully exploit COW potential.

As long as the main daemon (prior to accepting connections) does not
use much memory, it's not an issue. If it is an issue, just throw in
an extra hard drive that's always spun down with a few TB of swap
space and the commit allowance will go through the roof.

Also, if you'll be calling exec after fork, posix_spawn is available
as an option. On a good implementation, it can/will use vfork or some
other clone variant to avoid increasing the commit charge in the
window between fork and exec.

Rich