This is the first of the every-four-weeks MemShrink reports that I’m now doing. The 21 bugs fixed in the past four weeks include 11 leak fixes, which is great, but I won’t bother describing them individually. Especially when I have several other particularly impressive fixes to describe…

Image Handling

Back in March I described how Timothy Nikkel had greatly improved Firefox’s handling of image-heavy pages. Unfortunately, the fix had to be disabled in Firefox 22 and Firefox 23 because it caused jerky scrolling on pages with lots of small images, such as Pinterest.

Happily, Timothy has now fixed those problems, and so his previous change has been re-enabled in Firefox 24. This takes a big chunk out of the #1 item on the MemShrink big ticket items list. Fantastic news!

Lazy Bytecode Generation

Brian Hackett finished implementing lazy bytecode generation. This change means that JavaScript functions don’t have bytecode generated for them until they run. Because lots of websites use libraries like jQuery, in practice a lot of JS functions are never run, and we’ve found this 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.

The completion of this finished off item #5 on the old Memshrink big ticket items list. Great stuff. This will be in Firefox 24.

Add-on Memory Reporting

Nils Maier implemented add-on memory reporting in about:memory. Here’s some example output from my current session.

├───33,345,136 B (05.08%) -- add-ons │ ├──18,818,336 B (02.87%) ++ {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} │ ├──11,830,424 B (01.80%) ++ {59c81df5-4b7a-477b-912d-4e0fdf64e5f2} │ └───2,696,376 B (00.41%) ++ treestyletab@piro.sakura.ne.jp/js-non-window/zones/zone(0x7fbd7bf53800)

It’s obvious that Tree Style Tabs is taking up 2.7 MB. What about the other two entries? It’s not immediately obvious, but if I look in about:support at the “extensions” section I can see that they are AdBlock Plus and ChatZilla.

If you’re wondering why those add-ons are reported as hex strings, it’s due to a combination of the packaging of each individual add-on, and the fact that the memory reporting code is C++ and the add-on identification code is JS and there aren’t yet good APIs to communicate between the two. (Yes, it’s not ideal and should be improved, but it’s a good start.) Also, not all add-on memory is reported, just that in JS compartments; old-style XUL add-ons in particular can have their memory consumption under-reported.

Despite the shortcomings, this is a big deal. Users have been asking for this information for years, and we’ve finally got it. (Admittedly, the fact that we’ve tamed add-on leaks makes it less important than it used to be, but it’s still cool.) This will also be in Firefox 24.

b2g

Gregor Wagner has landed a nice collection of patches to help the Twitter and Notes+ apps on B2G.

While on the topic of B2G, in today’s MemShrink meeting we discussed the ongoing problem of slow memory leaks in the main B2G process. Such leaks can cause the phone to crash or become flaky after its been running for hours or days or weeks, and they’re really painful to reproduce and diagnose. Our partners are finding these leaks when doing multi-hour stress tests as part of their QA processes. In contrast, Mozilla doesn’t really have any such testing, and as a result we are reacting, flat-footed, to external reports, rather than catching them early ourselves. This is a big problem because users will rightly expect to have their phones run for weeks (or even months) without rebooting.

Those of us present at the meeting weren’t quite sure how we can improve our QA situation to look for these leaks. I’d be interested to hear any suggestions. Thanks!