[tbb-dev] Memory Allocators

Tom Ritter tom at ritter.vg
Mon May 11 18:59:21 UTC 2015

ESR38 isn't going to have jemalloc3.  But the code is in the FF tree,
well-integrated, and while I wouldn't call it 'supported', the mozilla
devs are at least pretty familiar with it.  I wanted to see if there
was anything that would stop Tor from potentially using it even if FF

The mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=762449

Their concerns are, at least:
 - mismatched calls to VirtualAlloc/Free:
https://github.com/jemalloc/jemalloc/issues/213 (This can be resolved
by a patch in comment #1 which is slower than they'd like)
 - performance concerns
 - I think there are issues on mobile platforms, but I'm not entirely
clear there

There are probably more, but these were the ones I was able to
discern.  I decided to test the performance question, with and without
the patch. I ran a slew of in-browser benchmark sites on an Ubuntu
desktop, running mozilla-release tag FIREFOX_38_0_RELEASE.

The results are close, and it looks like the current jemalloc (2?)
outperforms jemalloc3, but that jemalloc3 (even with the patch) is not
significantly more painful. Both compare favorably to chromium for


Bigger is better for all but the last chart (which labels it in the title).

If Tor wanted to consider turning on jemalloc3 in TBB, I would suggest
the following:
1) Seeing if the heap isolation based on class of object (e.g. js
strings/arrays) is implemented, and if not, what it would take to do
so. If it's not there and it's hard to do, there's not much point to
turning to jemalloc3
2) Round up the mozilla devs and lay it out as a real possibility and
get their input

I will work on #1 as I'm able.



More information about the tbb-dev mailing list