From owner-freebsd-current  Tue Apr 13 15:47:40 1999
Delivered-To: freebsd-current@freebsd.org
Received: from misha.cisco.com (misha.cisco.com [171.69.206.50])
	by hub.freebsd.org (Postfix) with ESMTP id 4FB7914C9C
	for <current@freebsd.org>; Tue, 13 Apr 1999 15:47:36 -0700 (PDT)
	(envelope-from mi@misha.cisco.com)
Received: (from mi@localhost)
	by misha.cisco.com (8.9.2/8.9.1) id SAA93415
	for current@freebsd.org; Tue, 13 Apr 1999 18:45:15 -0400 (EDT)
	(envelope-from mi)
From: Mikhail Teterin <mi@misha.cisco.com>
Message-Id: <199904132245.SAA93415@misha.cisco.com>
Subject: Re: swap-related problems
In-Reply-To: <13879.924034618@critter.freebsd.dk> from Poul-Henning Kamp at "Apr 13, 1999 10:16:58 pm"
To: current@freebsd.org
Date: Tue, 13 Apr 1999 18:45:15 -0400 (EDT)
Reply-To: mi@aldan.algebra.com
X-Mailer: ELM [version 2.4ME+ PL52 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Poul-Henning Kamp once wrote:

> >>     If you unset the datasize limit and the program does not exceed
> >>     the maximum system-supported datasize limit, malloc() should
> >>     not return NULL even if the system is out of swap.

> >Can you explain why? Our malloc(3) is a little fuzzy as to the
> >circumstances under which malloc will fail, but on Solaris, it is
> >more explicit:

> >	RETURN VALUES
> >		If there is no available memory, malloc(), realloc(),
> >		memalign(), valloc(), and calloc() return a null pointer.
> >
> >I consider being out-of-swap as having "no available memory". Wouldn't you?
 
> The trouble is, there is no such thing as "no available memory".

Well, this is just an implementation detail, is not it? I don't
mean to critisize, or anything, but such thing as "no available
memory" is a fairly intuitive... Coming down, again, the malloc
should return a usable memory if available and NULL if it's not.
Is not this a "natural" semantics? Why can a program die because
_another_ program ate up all the rest of the memory?

> What we have instead is "not enough memory available for this specific
> request".

> For phkmalloc I can say in particular that there is a pool for each
> size of chunk (16,32,64...2048 bytes and for pages. If you run out of
> one of these there may still be stuff in the other pools.

Then the malloc may need to take its time rearranging the pools,
or whatever... It gets it right if there is a datasize limit, right?
But the current behaviour under low-memory conditions seems wrong
to me, and is certainly different from what the Solaris' malloc(3C)
states.

	-mi

DISCLAIMER:
	a) this message was not meant to offend;
	b) I realize, the Solaris' malloc() may also be broken
	   in many ways;
	c) FreeBSD is rightfully the OS of choice for many (including
	   myself);
	d) I realize, that FreeBSD is wonderfull and I myself
	   use it _all_ i386 machines under my control and on
	   most i386 machines outside of my control.


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