Lots of news today.

Fixed Regressions

I wrote last time about a couple of bad regressions that AWSY identified.

Seth Fowler fixed the bigger of the two, which related to the handling of images. This won us back about 40 MB.

Peter Van der Beken ameliorated the smaller of the two on Aurora, which related to DOM bindings. This won back about 12 MB.

The ongoing DOM bindings work will hopefully fully fix the second regression before the end of this development cycle (February 18).

AWSY

John Schoenick made three big improvements to AWSY.

It now measures every push to mozilla-inbound. Previously it measured mozilla-central once per day. This will make it easier and faster to identify patches responsible for regressions.

It’s now possible to trigger an AWSY run for any try build. Unfortunately John hasn’t yet written instructions on how to do this; I hope he will soon…

AWSY now measures Fennec as well. Kartikaya Gupta created the benchmark that is used for this. He also fixed a 4 MB regression that it identified.

Leaks Fixed

Benoit Jacob fixed a CC leak that he found with his refgraph tool.

Johnny Stenback fixed a leak involving SVG that he found with DMD. This was a very slow leak that Johnny had seen repeatedly, which manifested as slowly increasing “heap-unclassified” values in about:memory over days or even weeks. It’s a really nice case because it shows that DMD can be used on long-running sessions with minimal performance impact.

Justin Lebar fixed a B2G leak relating to forms.js.

Randall Jesup fixed a leak relating to WebRTC.

Andrew McCreight fixed a leak relating to HTMLButtonElement.

Erik Vold fixed a leak in the Restartless Restart add-on.

Miscellaneous

Brian Hackett optimized the representation of JS objects that feature both array (indexed) elements and named properties. Previously, if an object had both elements and named properties, it would use a sparse representation that was very memory-inefficient if many array elements were present. This performance fault had been known for a long time, and it caused bad memory blow-ups every once in a while, so it’s great to have it fixed.

As a follow-up, Brian also made it possible for objects that use the sparse representation to change back to the dense array representation if enough array elements are subsequently added. This should also avoid some occasional blow-ups that occur when arrays get filled in in complex ways.

Gregory Szorc reduced the memory consumption of the new Firefox Health Report feature, from ~3 MB to ~1–1.5 MB: here and here and here and here. On a related note, Bill McCloskey is making good progress with reducing compartment overhead, which should be a sizeable win once it lands.

Gregory also reduced the memory consumption of Firefox Sync: https: here and here.

Jonathan Kew reduced the amount of memory used by textruns when Facebook Messenger is enabled.

The Add-on SDK is now present in mozilla-central, which is a big step towards getting all add-ons that use it to always use the latest version. This is nice because it will mean that when memory leaks in the SDK are fixed (and there have been many) all add-ons that use it will automatically get the benefit, without having to be repacked.

Generational GC

Generational garbage collection is an ongoing JS engine project that should reap big wins once it’s completed. I don’t normally write about things that haven’t been finished, but this is a big project and I’ve had various people asking about it recently, so here’s an update.

Generational GC is one the JS teams two major goals for the near-term. (The other is benchmark and/or game performance, I can’t remember which.) You can see from the plan that there are eight people working on it (though not all of them are working on it all the time).

Brian Hackett implemented a static analysis that can determine which functions in the JS engine can trigger garbage collection. On top of that, he then implemented a static analysis that can identify rooting hazards and unnecessary roots. This may sound esoteric, but it has massively reduced the amount of work required to complete exact rooting, which is the key prerequisite for generational GC. To give you an idea: Terrence Cole estimated that it reduced the number of distinct code locations that need to be looked at and possibly modified from ~10,000 to ~200! Great stuff.

Another good step was taken when I removed support for E4X from the JS engine. E4X is an old JavaScript language extension that never gained wide support and was only implemented in Firefox. The code implementing it was complicated, and an ongoing source of many bugs and security flaws. The removal cut almost 13,000 lines of code and over 16,000 lines of tests. It’s been destined for the chopping block for a long time, and its presence has been blocking generational GC, so all the JS team members are glad to see it go.

Bug Counts

Here are the current bug counts.

P1: 16 (-5/+0)

P2: 119 (-6/+0)

P3: 104 (-0/+0)

Unprioritized: 22 (-0/+18)

Three of the P1 “fixes” weren’t actual fixes, but cases where a bug was WONTFIXed, or downgraded. The unprioritized number is high because we skipped this week’s MemShrink meeting due to the DOM work week in London, which occupied three of our regular contributors.