Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Jan 2014 12:33:01 -0500
From: Rich Felker <>
Subject: Re: Re: Removing sbrk and brk

On Fri, Jan 03, 2014 at 11:51:32AM +0000, Thorsten Glaser wrote:
> Rich Felker <dalias <at>> 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).

> 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).


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.