jemalloc

Well Stuart is careful to say that jemalloc did well for Firefox specifically rather than just
saying that it's better for everyone. He doesn't actually give any GNU libc numbers for
comparison (unlike for Windows). Google and many others have provided alternative allocators,
it wouldn't be fair to characterise any of their differences as "drawbacks" necessarily, but
this is definitely a case where there are tradeoffs to be made.

Some allocators concentrate on the tiny allocations needed for all those variable length HTML
elements, filenames, email addresses, etc. they may be very efficient but in doing so use a
few more CPU cycles when you free() an item, or slowly fragment your address space over time
so that they're not acceptable in a program which runs for days or weeks at a time.

In some applications the allocator must absolutely be fast, above almost anything. Google, for
example, offer a really fast allocator but it will never† return heap memory to the OS.
Allocate some memory once, and you're stuck with it. You can re-use it, split it up, maybe
merge it with another allocation, but the Google allocator won't ever give it back for use by
other applications. If you've just visited myhugeimages.example.com and Firefox won't give
back the 600MB of memory it used rendering the site, this would be unacceptable.

In some applications, as in this Firefox example, fragmentation is determined to be a problem,
and the application is long-lived, it's OK to be a little slower, so long as you don't waste
memory or fragment the address space too much and so long as large allocations are returned
when no longer needed (avoiding fragmentation actually makes that easier).

Thread safety is another variable. Of course your allocator will run faster if it doesn't
worry about this at all, but some applications must have a thread safe allocator. Some will
even want to allocate memory in one thread and then later free it from a different thread.

The system / libc provided malloc is intended only to be a good default. If your application
is important enough to warrant writing or maintaining your own allocator, as has effectively
happened with jemalloc in Firefox, then you can stop using the C library's allocator and it's
smiles all round. GNU lib intentionally emits weak symbols for the allocator, making it easy
to choose your own instead.

† OK, on a decent modern OS, not until the program exits. If your OS doesn't track heap
allocations made by userspace, and so leaks RAM when apps crash, well - here's a nickel, get
yourself a real operating system kid.