Re: Re: Removing sbrk and brk

[Rich Felker <dalias@aerifal.cx>]

On Fri, Jan 03, 2014 at 11:51:32AM +0000, Thorsten Glaser wrote:
> Rich Felker <dalias <at> aerifal.cx> writes:
> 
> > sbrk may be re-added sometime after 1.0 if malloc is changed to no
> > longer use the brk (option 5 above).
> 
> You may want to import omalloc (based on mmap malloc, written from
> scratch by Otto Moerbeek) with lots of security features:

This discussion is about improving one aspect of malloc, not replacing
it with a third-party implementation. The reason musl is significantly
smaller and more maintainable than glibc and uclibc is that it's not a
hodge-podge of copy-and-paste from various legacy code. I suspect
omalloc is considerably higher quality than a lot of the things those
two implementations copied, but from casual inspection, it doesn't
look anywhere near as small or high-performance as musl's.

The actual motivation for moving to mmap in malloc is twofold:
preventing allocation failure when expansion of the brk is blocked by
an inconveniently-placed mapping, and unifying an idea I have in mind
for actually returning unneeded commit charge (right now, musl returns
unneeded physical memory but not commit charge).

> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/malloc.c
> http://www.openbsd.org/cgi-bin/man.cgi?query=malloc
> 
> It does assume that mmap() is randomised and NULs the result.

If so, this is a rather odd (incorrect) assumption and results in
highly suboptimal behavior (O(n) malloc in place of O(1), where n is
the size of the allocation).

Rich