Date: Fri, 16 Jul 1999 10:13:48 -0400 From: "Kelly Yancey" <kbyanc@alcnet.com> To: <hackers@FreeBSD.ORG> Subject: RE: freebsd-hackers-digest V4 #549 Message-ID: <000801becf95$6c007a80$291c453f@kbyanc.alcnet.com> In-Reply-To: <bulk.69925.19990716062410@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 16 Jul 1999 10:08:08 +1000
> From: "Andrew Reilly" <a.reilly@lake.com.au>
> Subject: Re: Swap overcommit
>
> On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote:
> > Actually, applications are written assuming that malloc() will not
> > fail, generally speaking.
>
> Is this really the case? I'm pretty sure I've _never_ ignored the
> possibility of a NULL return from malloc, and I've been using it
> for nearly 20 years. I usually print a message and exit, but I
> never ignore it. I thought that was pretty standard practise.
>
> This is just a random comment, orthogonal to the overcommit issue,
> but I've seen both you and Matthew say this now, and I was surprised
> both times.
>
> - --
> Andrew
>
I have to concur, I have only been programming in C for about 8 years
(although programming in other languages for about 15), and I am always sure
to check for the failure of dynamic memory allocation. Almost all malloc
calls I've written look something like (taken from actually source code):
if((current = malloc(sizeof(struct clientinfo))) == NULL)
die("Out of memory");
where die is simply a function which calls fprintf to write the message
out to stderr and then exit's the program with an error level of 1. Some
programs I've gotten fancier and added a second parameter to die() to
specify the error level to return.
In any event, I like to hope that everyone checks for malloc returning
null (since FreeBSD still returns NULL when the resource limit is hit). I
always have just assumed everyone did (actually, before this thread, I just
assumed returning NULL was more common than it is).
I'm all for overcommit, before this thread I never thought one way or the
other about it, but I feel that the case for overcommit has been made. And,
as is always the case, the offer has been extended for the proponents of
non-overcommit to put their source where their mouth is....needless to say
no one has stepped up.
The argument over overcommit vs. non-overcommit then is irrelevant until
someone from the non-overcommit produces patches so the world can see for
themselves what they are talking about. I would like to see the discussion
die.
On the other hand, I find the discussion about the merits of overcommit
and the (albeit not always in-depth) explanations of the FreeBSD VM system
educational. It would be nice if would could just extract the small amount
of signal from this discussion and put it into documentation somewhere.
Also, it has got me thinking: does FreeBSD overcommit memory allocated by
calloc()? Seems that it would be difficult since the page would have had to
have been touched in order be zeroed, but I was curious.
Thanks,
Kelly
~kbyanc@posi.net~
FreeBSD - The Power To Serve - http://www.freebsd.org/
Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD
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?000801becf95$6c007a80$291c453f>