Call for Help: Boehm+jemalloc

At the Firefox summit we decided to change tack on XPCOMGC and try to use Boehm instead of MMgc. Overall I think this was a really good decision. With help from Graydon, I even have some Linux builds that use Boehm under the hood (most memory is not considered collectable, only string buffers are collected objects at this point).

Unfortunately, while Boehm is a pretty good collector, it doesn’t do so well at memory allocation and fragmentation. Heap usage is between 1.5x and 2x that of standard Firefox using jemalloc. What I really want is a combination of jemalloc and Boehm, taking the best features from each:

Boehm Features:

jemalloc features:

Help Wanted

I’m looking for somebody who’s willing to painstakingly combine the best of these two allocators: either port the jemalloc low-fragmentation design to Boehm, or port the Boehm collection mechanism to the jemalloc allocator. If you’re interested, please contact me. Getting a solution to this problem really blocks any serious plans for further work on XPCOMGC.


  1. The key word is hardware. The MMgc solution failed because altering our codebase to have correct programmatic write barriers was going to involve boiling the ocean. And even with smart pointers, a standard MMgc write barrier involves a lot of overhead.
  2. In Boehm, parallel collection doesn’t work with most incremental collection, and so we may not actually decide to use it; avoiding large pauses with incremental collection is more important.

Atom Feed for Comments 3 Responses to “Call for Help: Boehm+jemalloc”

  1. Mitch Says:

    When you say “parallel collection”, you mean that the GC can run in parallel with the mutator, right? In that case, I’d think you’d end up with short mutator pauses just like with incremental collection, no?

  2. Benjamin Smedberg Says:

    No, I mean the that the collector stops the world, marks using multiple threads, and then restarts the world.

  3. Cameron Says:

    Designing a conservative concurrent mark-sweep collector for jemalloc shouldn’t be terribly hard. You just need to “hook” jemalloc to find 2 bits of per-block storage (for color), and you need to enumerate all allocated blocks. Most operating systems have calls for the hardware assisted write-barrier you’re looking for.

Leave a Reply