{"id":991,"date":"2011-07-06T11:49:06","date_gmt":"2011-07-06T00:49:06","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=991"},"modified":"2011-07-06T12:31:55","modified_gmt":"2011-07-06T01:31:55","slug":"memshrink-progress-week-3","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2011\/07\/06\/memshrink-progress-week-3\/","title":{"rendered":"MemShrink progress, week 3"},"content":{"rendered":"

This was the final week of development for Firefox 7, and lots of exciting MemShrink stuff happened.<\/p>\n

Per-compartment memory reporters<\/h3>\n

I landed per-compartment memory reporters<\/a>, using the new memory multi-reporter interface<\/a>.\u00a0 I’ve written previously<\/a> about per-compartment reporters;\u00a0 the number of things measured has increased since then, and each compartment now looks like this:<\/p>\n

\"Output<\/a><\/p>\n

One nice thing about this feature is that it gives technically-oriented users a way to tell which web sites are causing high memory usage.\u00a0 This may help with perception, too;\u00a0 people might think “geez, Facebook is using a lot of memory” instead of “geez, Firefox is using a lot of memory”.<\/p>\n

Another nice thing is that it can help find leaks.\u00a0 If you close all your tabs and some compartments are still around, that’s a leak, right?\u00a0 Actually, it’s more complicated than that:\u00a0 compartments are destroyed by the garbage collector, so there can be a delay.\u00a0 But there are buttons at the bottom of about:memory which force GC to occur, so if you press them and some compartments are still around, that’s a leak right?\u00a0 Well, it appears that sites that use timers can stick around while the timers are still live.\u00a0 For example, TBPL<\/a> appears to have a refresh timer that is 2 or 3 minutes long, so it’s compartment stays alive<\/a> for that long after the page is closed.\u00a0 (Actually, it’s not entirely clear if or why that should happen.)\u00a0 However, once you’ve accounted for these complications, any remaining compartments are likely to have leaked.<\/p>\n

Another thing to note is that the JS heap space used by each compartment is now reported.\u00a0 Also, the fraction of the JS heap that isn’t currently used by any particular compartment is also reported:<\/p>\n

\"Output<\/a><\/p>\n

Once this change landed, it didn’t take long to see that the “gc-heap-chunk-unused” number could get very large.\u00a0 In particular, if you browsed for a while, then closed all tabs except about:memory, then triggered heap minimization (via the buttons at the bottom of about:memory), you’d often see very large “gc-heap-chunk-unused” numbers.\u00a0 It turns out this is caused by fragmentation.\u00a0 The JS heap is broken into 1MB chunks, and often you’d end up with with a lot of almost-empty chunks, but they’d have a small number of long-lived objects in them keeping them alive, and thus preventing them from being deallocated.<\/p>\n

Reduced JavaScript heap fragmentation<\/h3>\n

Fortunately, Gregor Wagner had already anticipated this, and he tightened his grasp on the 2011 MemShrink MVP award by greatly reducing this fragmentation in the JavaScript heap<\/a>.\u00a0 Parts of Firefox itself are implemented in JavaScript, and many objects belonging to Firefox itself (more specifically, objects in the “system principal” and “atoms” compartments) are long-lived.\u00a0 So Gregor added simple chunk segregation;\u00a0 objects belonging to Firefox get put in one group of chunks, and all other objects (i.e. those from websites) get put in a second group of chunks.\u00a0 This made a huge difference.\u00a0 See this comment<\/a> and subsequent comments for some detailed measurements of a short browsing session;\u00a0 in short, the size of the heap was over 5x smaller (21MB vs. 108MB) after closing a number of tabs and forcing garbage collection.\u00a0 Even if you don’t force garbage collection, it still helps greatly, because garbage collection happens periodically anyway, and longer browsing sessions will benefit more than shorter sessions.<\/p>\n

This change will help everyday browsing a lot.\u00a0 It will also help with the perception of Firefox’s memory usage — once you learn about about:memory, an obvious thing to try is to browse for a while, close all tabs, and see what the memory usage looks like.\u00a0 Prior to this patch, the memory usage was often much higher than it is on start-up.\u00a0 With this patch, the usage is much closer to the usage seen at start-up.\u00a0 Ideally, it would be the same, and Justin Lebar opened a bug<\/a> to track progress on exactly this issue.<\/p>\n

There’s still room for reducing fragmentation in the JavaScript heap further.\u00a0 Kyle Huey has some good ideas in this bug<\/a>.<\/p>\n

Other bits and pieces<\/h3>\n