From owner-freebsd-hackers Mon Feb 26 9:59:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id BCC0F37B503 for ; Mon, 26 Feb 2001 09:59:45 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QHxj606269 for ; Mon, 26 Feb 2001 11:59:45 -0600 (CST) Message-Id: <200102261759.f1QHxj606269@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 09:55:57 PST." <200102261755.f1QHtvr34064@earth.backplane.com> Date: Mon, 26 Feb 2001 11:59:44 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102261755.f1QHtvr34064@earth.backplane.com>, Matt Dillon writes: > 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. I think we were talking about C, and there are reasonable GC implementations for C... that assume that they can detect an out-of-memory condition because malloc returns a null pointer. > 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. Fair enough, other circumstances might *also* cause a scan... but the fact remains that a GC system will want to know when it's out of memory, and will want some kind of warning other than a segfault. > 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. No one has said it solves all the problems. It solves *one specific* problem; the problem that you don't get *ANY* warning, or *ANY* chance to do anything, if you actually run out of available memory. Even if it's a transient failure that will go away in five minutes. Even if all you need to do is an fwrite and an fclose. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message