Re: Re: Removing sbrk and brk

[Rich Felker <dalias@aerifal.cx>]

On Mon, Jan 06, 2014 at 02:51:11PM +0000, Thorsten Glaser wrote:
> 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

Indeed, this makes sense.

> fragmentation properties are accepted because omalloc inserts
> unmapped guard pages between allocations and randomises them
> (via mmap) for proactive security reasons.

This seems to be optional behavior; using guard pages with all
allocations would blow up memory usage several thousand times and
limit the number of allocations possible on 32-bit systems to well
under one million -- yielding an unusable system.

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

In what way? The basic dlmalloc design musl uses is basically known
(albeit without any proof I'm aware of) to be the only efficient way
to do malloc. Pretty much all "improvements" to it actually sacrifice
O(1) operations or low fragmentation to buy performance improvements
in certain cases deemed likely (and of course making the worst-case
worse).

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

Might be interesting, but pretty off-topic. Using the OpenBSD malloc
in musl is not something that's really on the table.

Rich