[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140103173301.GU24286@brightrain.aerifal.cx>
Date: Fri, 3 Jan 2014 12:33:01 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: Removing sbrk and brk
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
