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/Interf...