{"id":2534,"date":"2013-03-20T16:19:29","date_gmt":"2013-03-20T05:19:29","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=2534"},"modified":"2013-03-20T16:19:29","modified_gmt":"2013-03-20T05:19:29","slug":"memshrink-progress-week-91-92","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2013\/03\/20\/memshrink-progress-week-91-92\/","title":{"rendered":"MemShrink progress, week 91–92"},"content":{"rendered":"

Bill McCloskey landed zones<\/a>, a.k.a. compartment groups.\u00a0 This mitigates the overhead of each compartment by allowing all compartments within a zone to share arenas and strings.\u00a0 Roughly speaking, each tab gets its own zone, and there’s a system zone for Firefox’s internal use.\u00a0 This was a MemShrink:P1 bug.<\/p>\n

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.\u00a0 The light green line (settled start-up) showed a ~6 MiB drop, which is ~10%.\u00a0 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.<\/p>\n

\"areweslimyet.com<\/a><\/p>\n

Avi Halachmi fixed a problem where badly managed gradients could cause spikes of 10s of MiBs when tab animations occurred<\/a>.\u00a0 This was a MemShrink:P1 bug.\u00a0 The fix has been backported to Aurora.<\/p>\n

Jed Parsons fixed excessive memory consumption by Persona after visiting the B2G marketplace<\/a>.\u00a0 At least, I think that’s what happened;\u00a0 I won’t pretend to genuinely understand what went on in that bug.\u00a0 This was a MemShrink:P1 bug.<\/p>\n

Fabrice Desr\u00e9 fixed a bad B2G leak relating to error messages<\/a>.\u00a0 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.<\/p>\n

I removed all uses of nsFixedSizeAllocator<\/a>.\u00a0 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<\/a>) from the codebase.<\/p>\n

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.\u00a0 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.\u00a0 Relatedly, I reduced the size of parse nodes<\/a> by 12.5% on 64-bit platforms, and 16.7% on 32-bit platforms.<\/p>\n

Interesting Open Bugs<\/h3>\n

Sometimes, especially on B2G, we have excessive memory consumption due to JS strings.\u00a0 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.\u00a0 Bug 852010<\/a> has been filed for this.\u00a0 It shouldn’t be too hard, as it would fit in with the existing JSON memory report dumping infrastructure.\u00a0 This is currently blocking bug 850893<\/a>, a B2G MemShrink:P1 bug.\u00a0 Please comment in the bug or contact me if you want to get involved.<\/p>\n

Bug 846616<\/a> and bug 850545<\/a> both are about high “heap-unclassified” values.\u00a0 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.\u00a0 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.<\/p>\n

Bug Status<\/h3>\n

Here are the current bug counts.<\/p>\n