Re: [PATCH] malloc: Use correct C11 atomics for fastbin

[Zack Weinberg <zack@owlfolio.org>]

DJ Delorie <dj@redhat.com> writes:

> Zack Weinberg via Libc-alpha <libc-alpha@sourceware.org> writes:
>> Every time we start talking about fastbins vs tcache again I start 
>> wondering, again, what's stopping us from replacing the entire malloc 
>> implementation with jemalloc,
>
> There's a couple of things, but they're technical details, not political
> ones:
>
> * There's a copy of a "mini-malloc" in the dynamic loader that needs to
>   be somewhat compatible with the full copy in libc.so so that data
>   allocated in the loader can be used later.

Hmm.  Why does the dynamic loader need to be able to allocate memory at
all, and how does it manage to play nice with LD_PRELOADed malloc
replacements if it does this?

> * The current malloc knows a lot about glibc internals like pthreads and
>   fork, so as to manage those boundaries properly (thread start/stop,
>   etc).

Similarly I am wondering how _this_ manages to work with LD_PRELOADed
malloc replacements.  (I confess I haven’t ever dug into this part of
glibc much at all.)

> * Benchmarks have shown that the various mallocs each have their strong
>   points and weak points, so expect some complaints about performance
>   loss when switching mallocs.  Your favorite allocator may perform
>   poorly in someone else's favorite application.
> * Testing, testing, testing.  Libc's malloc is used in all Linux distros
>   *and* Hurd, which means it's known to work with tens if not hundreds of
>   thousands of programs.  To propose a new system-wide allocator, you
>   need to replicate this level of effective testing.

It seems to me that this sets the bar for _any_ major change to glibc
malloc so high that it won’t ever happen, and given that every benchmark
_I’ve_ been pointed at shows glibc malloc coming in somewhere between
“mediocre” and “dead last”, that’s a shame.

zw