[tbb-dev] Memory Allocators

[Tom Ritter]

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
library.

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
"malloc-heap/latin1"
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:
http://www.canonware.com/download/jemalloc/jemalloc-latest/doc/jemalloc.html
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
arena.

- 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

-tom


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