Date: Mon, 26 Feb 2001 09:55:57 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Archie Cobbs <archie@dellroad.org>, Warner Losh <imp@village.org>, Peter Seebach <seebs@plethora.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <200102261755.f1QHtvr34064@earth.backplane.com> References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Matt Dillon wrote:
:>
:..
:> the system runs out of memory, even *with* overcommit protection.
:> In fact, all sorts of side effects occur even when the system
:...
:
:That's an assumption.
Ha. Right. Go through any piece of significant code and just see how
much goes flying out the window because the code wants to simply assume
things work. Then try coding conditionals all the way through to fix
it... and don't forget you need to propogate the error condition back
up the procedure chain too so the original caller knows why it failed.
:
:> There ain't no magic bullet here, folks. By the time you get a memory
:> failure, even with no overcommit, it is far too late to save the day.
:
:Scientific computation. If, at one point, no more memory can be
:allocated, you back off, save the present results, and try again later.
This is irrelevant to the conversation. It has nothing to do with
overcommit in the context it is being discussed.
:
:You assume too much. Quite a few of the more efficient garbage
:collection algorithms depend on knowing when the memory has become full.
This has nothing to do with overcommit in the context it is being
discussed. In fact, this has nothing to do with OS memory management
at all -- all garbage collected languages have their own infrastructure
to determine when memory pressure requires collecting.
:You keep allocating, and when malloc() returns NULL, *then* you run the
:garbage collector, free some space, and try again. If malloc() doesn't
:work, quite a few very efficient garbage collection algorithms become
:impossible to implement.
First, that's bullshit. Most garbage collection implementations
require the memory 'size' to be hardwired. Second, that's bullshit
because any program relying on that sort of operation had damn well
better have its datasize limit set to something reasonable, or the
garbage collector is going to run the system out of swap before it
decides it needs to do a run through.
:Just because *you* don't see how one thing can work, it doesn't mean it
:can't work. As I have trivially shown above.
You haven't shown anything above. Garbage collectors do not work that
way and you really should know it.
:Honestly, I think non-overcommit is a mistake and your approach is much
:better, but it's not the only approach and there _are_ valid approaches
:that depend on not overcommitting, and I really hate having to defend
:non-overcommit against such bogus arguments.
You've completely ignored the point that overcommit has nothing whatsoever
to do with memory pressure. You are assuming that overcommit is some
sort of magic bullet that will solve the memory pressure handling problem,
and it is nothing of the sort.
-Matt
:Daniel C. Sobral (8-DCS)
:dcs@newsguy.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102261755.f1QHtvr34064>