MemShrink’s 2nd Birthday

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.


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!

4 Responses to MemShrink’s 2nd Birthday

  1. Another great feature to have in Firefox by default would be to have a way to check up on an add-on’s memory. I seem to remember to have read that would be integrated, but I can be wrong there.

    Some time ago, I noticed about:blank (read: unloaded tabs) took megabytes of memory. Checking up on about:memory now, that seems to have been reduced to 150-200kB each, so great job on that :)

    And to finish: are there still plans to “hibernate” tabs that have been unused for a while?

    • Nicholas Nethercote

      Re add-ons, will land on Monday (or possibly even today)! That’s why I didn’t include it in the list, it seemed like it would be cheating to include an item I knew was about to be finished :)

      The not-yet-loaded tabs situation was greatly improved by There are no plans for further improvements, because we’re well into diminishing-returns territory on that one. is the tab hibernation bug. It’s been implemented on mobile, but it’s controversial on desktop due to the difficulty of guaranteeing that data won’t be lost. (On mobile, the user expectation of data retention is lower, which is why it was able to be done there.)

      • Ooh, the add-ons being added to about:memory is very cool news! Great job!

        I know about the unloaded tabs, the comment about that was just to congratulate you guys on your great work :)

        I also follow the bug about hibernated tabs, but I saw there hasn’t been any activity since last year, so I was wondering if it was still on the radar.

        Thanks for all the information!

  2. Tacking on to a comment from the previous blog post, which is now read-only, I also have noticed that RSS (in fact, all measurements except the miscellaneous ones) have regressed by something like 20% since March 2012. Is this on your radar?