[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <loom.20140106T154833-597@post.gmane.org>
Date: Mon, 6 Jan 2014 14:51:11 +0000 (UTC)
From: Thorsten Glaser <t.glaser@...ent.de>
To: musl@...ts.openwall.com
Subject: Re: Removing sbrk and brk
Rich Felker <dalias <at> aerifal.cx> writes:
> > Overall my assessment is that omalloc is _simple_ (in some ways
> > simpler than musl's), but looks to have much worse fragmentation
> > properties, much worse performance properties (both syscall overhead
> > and locking come to mind), and no other clear advantages.
I think the idea behind simplicity was ease of auditing, and the
fragmentation properties are accepted because omalloc inserts
unmapped guard pages between allocations and randomises them
(via mmap) for proactive security reasons.
> tight packing of small allocations. It also provides greater
> protection against corruption of the internal malloc structures, in
Indeed.
> the sense of allowing the program to keep going after overflows, but
> less ability to catch overflows and less protection from corrupting
> other application data, unless you add back overhead just for that
> purpose.
Such as the guard pages, yes.
But I guess it depends on whether you want to optimise for speed.
On the other hand, just the suggestion of reverting (in my eyes)
to the musl behaviour of having a heap that’s grown/shrunk dynamically
for smaller objects smells weird to me (with the BSD developer hat on).
But I’m just a downstream of omalloc. I really suggest to talk to
Otto Moerbeek, who, in contrast to most OpenBSD developers, is
pleasant to talk with and approachable.
bye,
//mirabilos
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.
