On Wed, 19 Feb 1997, Bill Bogstad wrote:
>
> Bret Hollon wrote:
>
> >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?
[snip]
> 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.
Or, perhaps the other way around. The majority of developers are going to
want non-committed allocations, for the simple reason that it helps one's
application co-exist with others. If the system enters into a situation
where VM has become so sparse that the allocations I had previously been
granted can no longer be met, it's a good bet that the whole enchilada is
headed for dangerous waters. 99% of the time I would rather segfault, try
to clean up gracefully and get out of the way of everyone else.
Certainly, in a few instances it might be desireable to have truely
committed allocations, but changing the allocation operation completely
could cause a problem for existing applications (especially on lower end
systems).
+-------------------------------------------------------------------+
+ -- Finger: flood@evcom.net for my PGP public key -- +
+-------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMwuGOhsjWkWelde9AQF6ggQA1b+CVfndJ0uSQefT3NkYdGMjzCNC+25z
gU7QTaEnZdjbncJUnW9vkNY5YiiUbWLI+oxuhlbWYCabVb9MATQVjHJYJqLzZBNZ
CVb6TTMNdXTaQbLX6Lw1CVBl455MMniPFH21A+K54CZ9Ydr/Zdp0lFxxi1PkHpEf
xNmytmU3wXI=
=Mzdf
-----END PGP SIGNATURE-----