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.