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.