June 14, 2013 is the second anniversary of the first MemShrink meeting. This time last year I took the opportunity to write about the major achievements from MemShrink’s first year. Unsurprisingly, since then we’ve been picking fruit from higher in the tree, so the advances have been less dramatic. But it’s been 11 months since I last update the “big ticket items” list, so I will take this opportunity to do so, providing a partial summary of the past year at the same time.
The Old Big Ticket Items List
#5: Better Script Handling
This had two parts. The first part was the sharing of immutable parts of scripts, which Till Schneidereit implemented. It can save multiple MiBs of memory, particular if you have numerous tabs open from the same website.
The second part is lazy bytecode generation, which Brian Hackett has implemented and landed, though it hasn’t yet enabled. Brian is working out the remaining kinks and hopes to land by the end of the current (v24) cycle. Hopefully he will, because measurements have shown that it can reduce Firefox’s memory consumption by 5% or more on common workloads! That’s a huge, general improvement. Furthermore, it significantly reduces the number of things that are allocated on the GC heap (i.e. scripts, strings, objects and shapes that are created when bytecode for a function is generated). This reduces pressure on the GC which makes it less likely we’ll have bad GC behaviour (e.g. pauses, or too much memory consumption) in cases where the GC heuristics aren’t optimal.
So the first part is done and the second is imminent, which is enough to cross this item off the list. [Update: Brian just enabled lazy bytecode on trunk!]
#4: Regain compartment-per-global losses
Bill McCloskey implemented zones, which restructured the heap to allow a certain amount of sharing between zones. This greatly reduced wasted space and reduced memory consumption in common cases by ~5%.
Some more could still be done for this issue. In particular, it’s not clear if things have improved enough that many small JSMs can be used without wasting memory. Nonetheless, things have improved enough that I’m happy to take this item off the list.
#3: Boot2Gecko
This item was about getting about:memory (or something similar) working on B2G, and using it to optimize memory. This was done some time ago and the memory reporters (plus DMD) were enormously helpful in improving memory consumption. Many of the fixes fell under the umbrella of Operation Slim Fast.
So I will remove this particular item from the list, but memory optimizations for B2G are far from over, as we’ll see below.
#2: Compacting Generational GC
See below.
#1: Better Foreground Tab Image Handling
See below.
The New Big Ticket Items List
#5: pdf.js
pdf.js was recently made the default way of opening PDFs in Firefox, replacing plug-ins such as Adobe Reader. While this is great in a number of respects, such as security, it’s not as good for memory consumption, because pdf.js can use a lot of memory in at least some cases. We need to investigate the known cases and improve things.
#4: Dev tools
While we’ve made great progress with memory profiling tools that help Firefox developers, the situation is not nearly as good for web developers. Google Chrome has heap profiling tools for web developers, and Firefox should too. (The design space for heap profilers is quite large and so Firefox shouldn’t just copy Chrome’s tools.) Alexandre Poirot has started work on a promising prototype, though there is a lot of work remaining before any such prototype can make it into a release.
#3: B2G Nuwa
Cervantes Yu and Thinker Li have been working on Nuwa, which aims to give B2G a pre-initialized template process from which every subsequent process will be forked. This might sound esoteric, but the important part is that it greatly increases the ability for B2G processes to share unchanging data. In one test run, this increased the number of apps that could be run simultaneously from five to nine, which is obviously a big deal. The downside is that getting it to work requires some extremely hairy fiddling with low-level code. Fingers crossed it can be made to work reliably!
Beyond Nuwa, there is still plenty of other ways that B2G can have its memory consumption optimized, as you’d expect in an immature mobile OS. Although I won’t list anything else in the big ticket items list, work will continue here, as per MemShrink’s primary aim: “MemShrink is a project that aims to reduce the memory consumption of Firefox (on desktop and mobile) and Firefox OS.”
#2: Compacting Generational GC
Generational GC will reduce fragmentation, reduce the working set size, and speed up collections. Great progress has been made here — the enormous task of exactly rooting the JS engine and the browser is basically finished, helped along greatly by a static analysis implemented by Brian Hackett. And Terrence Cole and others are well into converting the collector to be generational. So we’re a lot closer than we were, but there is still some way to go. So this item is steady at #2.
#1: Better Foreground Tab Image Handling
Firefox still uses much more memory than other browsers on image-heavy pages. Fortunately, a great deal of progress has been made here. Timothy Nikkel fixed things so that memory usage when scrolling through image-heavy pages is greatly reduced. However, this change caused some jank on pages with lots of small images, so it’s currently disabled on the non-trunk branches. Also, there is still a memory spike when memory-heavy pages are first loaded, which needs to be fixed before this item can be considered done. So this item remains at #1.
Summary
Three items from the old list (#3, #4, #5) have been ticked off. Two items remain (#1, #2) — albeit with good progress having been made — and keep their positions on the list. Three items have been added to the new list (#3, #4, #5).
Let me know if I’ve omitted anything important!
