{"id":1964,"date":"2012-06-15T10:43:46","date_gmt":"2012-06-14T23:43:46","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1964"},"modified":"2012-06-15T10:43:46","modified_gmt":"2012-06-14T23:43:46","slug":"memshrinks-1st-birthday","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2012\/06\/15\/memshrinks-1st-birthday\/","title":{"rendered":"MemShrink’s 1st Birthday"},"content":{"rendered":"

A year ago today, the first meeting of the MemShrink project<\/a> took place.\u00a0 The project had been announced<\/a> almost three months earlier, but until that first meeting it was basically just me working on it and there wasn’t much momentum.\u00a0 So I now think of those three months as something of a gestation period, and the first meeting as the true birth of the project.<\/p>\n

So, happy birthday, MemShrink!\u00a0 I’ll take this opportunity to go over some of the accomplishments we’ve made in the past year.<\/p>\n

Big Win #1: Better Javascript Heap Management<\/h3>\n

There have been two huge MemShrink improvements that stand out in my mind.\u00a0 The first one happened very early on, and it consisted of two related changes, both implemented by Gregor Wagner.<\/p>\n

In Firefox 4, the implementation of the JavaScript heap was totally overhauled.\u00a0 In particular, it was segregated into compartments<\/a>, each of which held (roughly speaking) the memory for a single domain.\u00a0 System compartments, i.e. those for JavaScript code that implements parts of Firefox (such as the UI), tend to be long-lived.\u00a0 In contrast, user compartments, i.e. those for JavaScript code in web pages, tend to be short-lived.\u00a0 But memory from both system and user compartments was being co-located in 1MB chunks.\u00a0 What tended to happen is that if you browsed for a long time and then closed many tabs, you’d end up with lots of 1MB chunks that were kept alive by a small amount of memory from system compartments.\u00a0 This is a form of fragmentation, and it prevented Firefox from releasing lots of memory back to the operating system that it should have been able to.<\/p>\n

Fortunately, Gregor came up with a simple fix:\u00a0 don’t allow system and user compartments to share the same 1MB chunks<\/a>.\u00a0 To see just how effective this was, consider this visualization of the JavaScript heap after closing many tabs, without Gregor’s change.<\/p>\n

\"badly<\/p>\n

Each horizontal line is a 1MB chunk, and each square is a 4KB arena.\u00a0 White squares are unused arenas, and coloured squares are in use.\u00a0 Arenas belong to a particular compartment all have the same colour;\u00a0 there are three compartments alive, all of which are system compartments.\u00a0 You can see that many 1MB chunks are kept alive by a small number of arenas.<\/p>\n

After Gregor’s change, in this scenario the heap ended up looking like this.<\/p>\n

\"non-fragmented<\/p>\n

Much<\/em> better.<\/p>\n

Gregor’s second change related to garbage collection scheduling.\u00a0 In Firefox 4 the garbage collection heuristics were poorly tuned, and the garbage collector simply didn’t run frequently enough.\u00a0 Many people who left Firefox open for a while came back to find that JavaScript memory consumption had ballooned, and the machine was unusable due to paging, for seconds or minutes, until the garbage collector kicked in and paging finished.\u00a0 The fix was simple:\u00a0 run the garbage collector occasionally, using a timer<\/a>.<\/p>\n

These two fixes of Gregor were the main reason why the first item in the Firefox 7 release note<\/a>s was “drastically improved memory handling<\/a> for certain use cases”.\u00a0 More specifically, Firefox 7 used less memory than Firefox 6 (and 5 and 4): often 20% to 30% less, and sometimes as much as 50% less<\/a>.<\/p>\n

Big Win #2: Fewer add-on Leaks<\/h3>\n

The second huge MemShrink improvement is much more recent.\u00a0 In fact it hasn’t even made it into a released version of Firefox yet.\u00a0 And the path towards it was much more circuitous.<\/p>\n

I first<\/a> revamped<\/a> about:memory<\/a> in May of last year, and those changes made it into Firefox 6. This started giving us insight into Firefox’s memory consumption, but it wasn’t until I broke up the reporting of JS memory consumption on a per-compartment basis<\/a> that it really started to make a difference.\u00a0 (This change made it into Firefox 7, another reason why that release was so good from a memory consumption point of view.)<\/p>\n

Per-compartment reporters made some blatant inefficiencies<\/a> obvious, which were quickly fixed.\u00a0 More importantly, people quickly noticed that sometimes compartments were present for sites that had been closed long ago.\u00a0 This is a kind of memory leak that became known as a zombie compartment<\/a>, and hunting them became a popular enough sport that\u00a0 more than 100 zombie compartment bug reports<\/a> have been filed.<\/p>\n

Some of the zombie compartments were due to defects in Firefox itself, and these were generally fixed fairly quickly.\u00a0 However, it soon became clear that the majority of them are due to add-ons<\/a>.\u00a0 It’s quite easy<\/a> to unintentionally create zombie compartments in add-ons.\u00a0 In the worst case<\/a>, add-ons could leak the compartment of every single site visited.<\/p>\n

This led to some lively discussion about how best to handle these leaks, because they are defects in third-party code that is largely out of Mozilla’s control, and yet they make Firefox look bad.\u00a0 Fortunately, this discussion became mostly moot when Kyle Huey took advantage of an 8,000 mile trip from home to implement a crazy idea he’d had six months earlier —\u00a0 when a tab is closed, simply cut the references from other compartments<\/a> that would keep the compartment of the tab’s page alive.\u00a0 This turns out to work tremendously well<\/a> and prevents most of the cases where add-ons can create zombie compartments.\u00a0 This change is scheduled to ship in Firefox 15, which is due for release in late August, and should more or less fix what I six months ago ranked as the single worst problem<\/a> affecting Firefox’s memory consumption.<\/p>\n

The Key Tool: Memory Reporters and About:memory<\/h3>\n

I mentioned about:memory above.\u00a0 It’s worth discussing in more detail, because it’s the single most important tool we’ve created, and has driven a lot of the MemShrink improvements.<\/p>\n

Let’s look at about:memory as it was in Firefox 6, which was released about 10 months ago.\"about:memory<\/a><\/p>\n

Even these early versions had several key properties.<\/p>\n