[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180731004728.GD1392@brightrain.aerifal.cx>
Date: Mon, 30 Jul 2018 20:47:28 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: malloc implementation survey: omalloc
On Sun, Jul 29, 2018 at 09:26:18PM +0200, Markus Wichmann wrote:
> Hi all,
>
> we discussed rewriting malloc() a while back, because, as I recall, Rich
> wasn't satisfied with the internal storage the current system is using
> (i.e. metadata is stored with the returned pointer) as well as some
> corner cases on lock contention, although fine grained locking is a nice
> feature in itself.
>
> I therefore had a look at existing malloc() algorithms, the rationale
> being that I thought malloc() to be a solved problem, so we only have to
> find the right solution.
>
> As it turns out, it appears Doug Lea was simply too successful: Many
> allocators follow his pattern in one way or another. But some systems
> buck the trend.
>
> So today I found omalloc, the allocator OpenBSD uses, in this nice
> repository:
>
> https://github.com/emeryberger/Malloc-Implementations
I haven't looked at it in a couple years, but last I did, the OpenBSD
allocator was not practical. It used individual mmaps for even
moderately large allocations, and used guard pages with each, which
with the default Linux VMA limits puts an upper bound of 32768 on the
number of non-tiny (roughly, larger-than-page IIRC) allocations.
It does have much stronger hardening against overflows than musl's
current malloc or any other allocator, but it seemed inferior in all
other ways.
I'll read the rest of your description later and see if there's
anything new that's interesting.
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.
