Bill McCloskey landed zones, a.k.a. compartment groups. This mitigates the overhead of each compartment by allowing all compartments within a zone to share arenas and strings. Roughly speaking, each tab gets its own zone, and there’s a system zone for Firefox’s internal use. This was a MemShrink:P1 bug.
The following graph from areweslimyet.com shows the impact of zones — about 5/6 of the way along the graph there’s a distinct drop, most noticeable in the dark blue line. The light green line (settled start-up) showed a ~6 MiB drop, which is ~10%. Note that the fraction of JS memory in areweslimyet.com is less than that in typical sites, so the drop in the higher lines is smaller than the improvements normal users should see.
Avi Halachmi fixed a problem where badly managed gradients could cause spikes of 10s of MiBs when tab animations occurred. This was a MemShrink:P1 bug. The fix has been backported to Aurora.
Jed Parsons fixed excessive memory consumption by Persona after visiting the B2G marketplace. At least, I think that’s what happened; I won’t pretend to genuinely understand what went on in that bug. This was a MemShrink:P1 bug.
Fabrice Desré fixed a bad B2G leak relating to error messages. This bug was fixed before it was triaged in a MemShrink meeting, but it probably would have been a MemShrink:P1 because it could cause the phone to OOM after a few hours.
I removed all uses of nsFixedSizeAllocator. This was only a small memory consumption win (a few 10s of KiBs) but it cut several hundred lines of code, and removed another low-quality custom allocator (and attractive nuisance) from the codebase.
I added a “js-main-runtime-temporary-peak” memory reporter, which measures the peak size of the main JSRuntime’s “temporary” pool, which mostly holds parse nodes. These are short-lived but they can be quite large — 10s of MiBs in normal browsing, and we’ve seen it exceed 1.5 GiB on large asm.js examples. Relatedly, I reduced the size of parse nodes by 12.5% on 64-bit platforms, and 16.7% on 32-bit platforms.
Interesting Open Bugs
Sometimes, especially on B2G, we have excessive memory consumption due to JS strings. It would be useful to be able to dump the contents of all the strings in memory, to look for ones that shouldn’t be there. Bug 852010 has been filed for this. It shouldn’t be too hard, as it would fit in with the existing JSON memory report dumping infrastructure. This is currently blocking bug 850893, a B2G MemShrink:P1 bug. Please comment in the bug or contact me if you want to get involved.
Bug 846616 and bug 850545 both are about high “heap-unclassified” values. Reducing “heap-unclassified” is getting very difficult, because the memory is often allocated in ways we can’t measure by third-party code such as Cairo and graphics drivers. I suppose in the Cairo case we could put effort into adding some memory profiling infrastructure and try to get it upstreamed, but the driver situation seems pretty hopeless.
Here are the current bug counts.
- P1: 13 (-3/+4)
- P2: 134 (-2/+8)
- P3: 124 (-4/+6)
- Unprioritized: 4 (-6/+4)