>I can see a very serious problem with this. Just how can you tell
>the difference between a hardware failure, buffer overrun, ignored
>return value from malloc, (any other of a number of ways you can
>generate a seg fault through programming errors), and bumping into
>one of these over-committed memory areas?
I've seen this issue come up before and there are sound arguments on
both sides. I believe that IRIX has the ability to not commit swap space at
fork() time. The explanation was that if you have some huge data intensive
graphics program that wants to fork() & exec() a shell to do a shell escape;
you don't want to have to commit that much swap space when you plan to throw
it away after the exec(). Perhaps worse, you limit the largest program which
can do a fork(). If a systems maximuum virtual space (real memory plus swap
space) is 128M, then no process larger then 64M can every do a fork() if you
require commited memory space.
When dealing with malloc() (actually brk()/sbrk()), I believe the
issue is that some programs/languages like to allocate huge chunks of memory
which they may or may not make use of. If you actually allocate swap space
to such processes, you limit how many of them you can run on a machine even
thought they don't really need that much space.
Counter arguments, as you suggest, can be made about the problems
that this will cause. In addition, to those you mention there is also the
principle of 'least astonishment'. Historically, UNIX systems have
committeed space when a malloc() occurs and you are introducing a new failure
modes for programs. I don't think I'ld want my database server to suddenly
die when it got a segment fault because the space wasn't REALLY there for
the memory the kernel claimed to have allocated.
Personally, I think the default should be to commit space and there
should be a system call which lets programs that do want to overcommit to do
so.
Bill