From owner-freebsd-hackers Mon Feb 26 9:56:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id AD17F37B491 for ; Mon, 26 Feb 2001 09:56:07 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QHtvr34064; Mon, 26 Feb 2001 09:55:57 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 09:55:57 -0800 (PST) From: Matt Dillon Message-Id: <200102261755.f1QHtvr34064@earth.backplane.com> To: "Daniel C. Sobral" Cc: Archie Cobbs , Warner Losh , Peter Seebach , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102260628.f1Q6SYX29811@earth.backplane.com> <3A9A0A9A.E4D31F97@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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