[tbb-dev] Memory Allocators

Tom Ritter tom at ritter.vg
Tue May 19 04:27:51 UTC 2015

Progress! Although I missed the meeting, sorry.

Adding this patch:
https://bug1052573.bugzilla.mozilla.org/attachment.cgi?id=8573433 to
FF38 (plus enabling jemalloc3) means we have heap partitioning
functions available to both Firefox proper (I believe) and a replace

I have successfully implemented a replace library that creates arenas
and mallocs things into them.

Then I went and traced down how memory tags work.  Bad news. As I
understand them, there's no real metadata about the tag available.
Rather different parts of the FF Codebase implement
nsIMemoryMultiReporter[0], which calls some functions, which
self-reports allocated data into buckets.  For an example:

look at js/xpconnect/src/XPCJSRuntime.cpp
JSReporter::CollectReports calls (among other things) ReportZoneStats
ReportZoneStats reports the mallocHeapLatin1 member as the tag
The mallocHeapLatin1 member is the number of bytes used for that type
of bucket, and is filled in js/src/vm/MemoryMetrics.cpp
Specifically, we track the memory as being "malloc-heap/latin1" when
we call StatsCellCallback, which is called by JS::CollectRuntimeStats

My point is: at allocation time, I don't see any way to use these
memory tags to direct allocation.

Future directions:

Find the allocations of the most dangerous JS types (strings, arrays),
and switch their allocations over to partitions.  Just patch the code
ourselves. Can we put our patches behind a preference? ...Probably...
I think?  Assuming we're using jemalloc3 (compiled in, no preference,
just always on) I don't think allocating without or with arenas or
switching in the middle of things is a problem.  Obviously we'd test
but, it seems like it would work.

I don't even think it matters for things like reallocs.  Specifically:
Look for the non-standard APIs that accept a flags argument. You use
the macro MALLOCX_ARENA(int) as a flag to allocate in a specific

- The Non-Standard API does not define a free() that requires you to
pass in the arena it was allocated to. You do not need to preserve
that information anywhere, you can just free a pointer.
- The rallocx() and xallocx() functions does not say you must
reallocate in the same arena you allocated in

Write a replace library that randomizes the arena based on the
callstack.  (Yep, I'm still pushing this. =P)

When there's a ESR38 TBB I'll start working off that instead of mozilla-release


[0] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMemoryMultiReporter

More information about the tbb-dev mailing list