From owner-freebsd-hackers  Sat Feb 24 12:37:55 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 C624137B503
	for <freebsd-hackers@freebsd.org>; Sat, 24 Feb 2001 12:37:52 -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 f1OKbd618343;
	Sat, 24 Feb 2001 14:37:39 -0600 (CST)
Message-Id: <200102242037.f1OKbd618343@guild.plethora.net>
From: seebs@plethora.net (Peter Seebach)
Reply-To: seebs@plethora.net (Peter Seebach)
To: Dag-Erling Smorgrav <des@ofug.org>
Cc: freebsd-hackers@freebsd.org
Subject: Re: Setting memory allocators for library functions. 
In-reply-to: Your message of "24 Feb 2001 21:28:49 +0100."
             <xzpg0h37rlq.fsf@flood.ping.uio.no> 
Date: Sat, 24 Feb 2001 14:37:39 -0600
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <xzpg0h37rlq.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
>Malloc() does not overcommit - the kernel does. Malloc() doesn't know
>and doesn't care.

But it could still probably force the behavior.

>None of these solutions are portable, however;

Well, no, but the sole available definition of "portable" says that it is
"portable" to assume that all the memory malloc can return is really
available.

>memory overcommit is to write a malloc() wrapper that installs a
>SIGSEGV handler, then tries to dirty the newly allocated memory, and
>fails gracefully if this causes a segfault.

Ugh.  Why not just have a flag for memory requests that requires the memory
not to be overcommitted, and set it in "conforming mode"?  The kernel *could*
have memory which must not be overcommitted.

-s

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message