[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Nov 2019 00:54:35 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: New malloc - first preview
On Fri, Nov 29, 2019 at 08:55:23AM -0500, Rich Felker wrote:
> On Fri, Nov 29, 2019 at 09:37:15AM +0300, Vasya Boytsov wrote:
> > Is your malloc implementation any better than
> > https://github.com/microsoft/mimalloc?
> > AFAIK one can use mimalloc in their projects as it has compatible license.
> > the only thing that bothers is that it is done by Microsoft research.
>
> "Better" is not meaningful without specifying criteria for evaluation.
> The information on mimalloc is sparse, not covering the basic design
> it uses AFAICT, rather mainly the new properties it has which are
> mostly for the purpose of its specialized sharding API (not
> useful/usable for malloc API). So without reading into it much more,
> it's hard to say.
I've done a bit more reading of the source (mainly headers) and it
looks like this allocator is in the "extreme performance at the
expense of extreme size costs" camp with jemalloc, etc. It allocates
"segments" of 2MB at a time from the OS, with 2MB alignment (this
probably kills ASLR effectiveness), and splits them up into 512k or
64k "pages" (which becomes an overloaded term) belonging to particular
threads. It looks like each "page" consists of blocks all of the same
size, so that, for N threads each using M different allocation sizes,
you're consuming at least N*M*64k of memory.
So indeed, it looks like it's not using an approach that's relevant to
musl.
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.
