Steve Kargl once wrote:

> Then, submit your patches to fix the problem preferably with a knob to
> turn your patches on/off. From the discussion, I hope you're prepared
> to deal with the following scenario:
I'll be prepared... I don't think it should be a compile time option,
though. May be kernel-compile-time -- malloc isn't really at fault here,
it seems... But rather a run-time.

>   User:    I compiled malloc with -DSTRICT_ANSI.  Now my system appears
>            sluggish and I can't run as many processes because of
>            memory/swap starvation.  
> Submit your patches to the documentation pointing out the alleged
> shortcomings malloc() and friends.

"Alleged" :-)
> Meanwhile, visit /usr/ports.

> /usr/ports/devel/libxalloc
> /usr/ports/devel/libmalloc
> /usr/ports/devel/libdlmalloc

I do not see how they can guarantee the usability of the returned
memory with the current kernel. There apparently is no way of
knowing at malloc time if the memory can be used. Worse then that,
it may be possible to use it at malloc time, but unless your program
runs and touches every page, the memory may not be available later.

If we are up to discussing the possible implementations, I'd suggest
that the system uses something other then SIGKILL to notify the
program it's time to pay for the over-commit speed and convenience.
I think, SIGBUS is appropriate, but I'm not sure.

Anything a program can _catch_ and react upon, if its author chooses

Then, one can write a safe malloc, which will install the signal
handler, and touch every page in the the memory referenced by the
to-be-returned pointer. If the signal handler is invoked in the
progress, the to-be-returned memory must be returned back to the
system and NULL should be returned to the caller.

Whether or not to use this "safe" malloc can be determined by malloc
options and/or the size of the request.

However, my (in)ability to propose anything remotely sensible does
not change the facts established in this painful thread. That our
malloc does not conform to standards (for whatever reasons), and
that something should be done about it. That "something" must start
with documenting the flaw...


To Unsubscribe: send mail to
with "unsubscribe freebsd-current" in the body of the message

Reply via email to