Lots of news today.<\/p>\n
I wrote last time<\/a> about a couple of bad regressions that AWSY identified.<\/p>\n The ongoing DOM bindings work will hopefully fully fix the second regression before the end of this development cycle (February 18).<\/p>\n John Schoenick made three big improvements to AWSY<\/a>.<\/p>\n Benoit Jacob fixed a CC leak<\/a> that he found with his refgraph<\/a> tool.<\/p>\n Johnny Stenback fixed a leak involving SVG<\/a> that he found with DMD.\u00a0 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.\u00a0 It’s a really nice case because it shows that DMD can be used on long-running sessions with minimal performance impact.<\/p>\n Justin Lebar fixed a B2G leak relating to forms.js<\/a>.<\/p>\n Randall Jesup fixed a leak relating to WebRTC<\/a>.<\/p>\n Andrew McCreight fixed a leak relating to HTMLButtonElement<\/a>.<\/p>\n Erik Vold fixed a leak in the Restartless Restart add-on<\/a>.<\/p>\n Brian Hackett optimized the representation of JS objects that feature both array (indexed) elements and named properties<\/a>.\u00a0 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.\u00a0 This performance fault had been known for a long time<\/a>, and it caused bad memory blow-ups every once in a while, so it’s great to have it fixed.<\/p>\n 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<\/a>.\u00a0 This should also avoid some occasional blow-ups that occur when arrays get filled in in complex ways.<\/p>\n Gregory Szorc reduced the memory consumption of the new Firefox Health Report feature, from ~3 MB to ~1–1.5 MB: here<\/a> and here<\/a> and here<\/a> and here<\/a>. On a related note, Bill McCloskey is making good progress with reducing compartment overhead<\/a>, which should be a sizeable win once it lands.<\/p>\n Gregory also reduced the memory consumption of Firefox Sync:\u00a0\u00a0https: here<\/a> and here<\/a>.<\/p>\n Jonathan Kew reduced the amount of memory used by textruns when Facebook Messenger is enabled<\/a>.<\/p>\n The Add-on SDK is now present in mozilla-central<\/a>, which is a big step towards getting all add-ons that use it to always use the latest version.\u00a0 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.<\/p>\n Generational garbage collection is an ongoing JS engine project that should reap big wins once it’s completed.\u00a0 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.<\/p>\n Generational GC is one the JS teams two major goals for the near-term.\u00a0 (The other is benchmark and\/or game performance, I can’t remember which.)\u00a0 You can see from the plan<\/a> that there are eight people working on it (though not all of them are working on it all the time).<\/p>\n Brian Hackett implemented a static analysis that can determine which functions in the JS engine can trigger garbage collection<\/a>.\u00a0 On top of that, he then implemented a static analysis that can identify rooting hazards and unnecessary roots<\/a>.\u00a0 This may sound esoteric, but it has massively reduced the amount of work required to complete exact rooting<\/a>, which is the key prerequisite for generational GC.\u00a0 To give you an idea:\u00a0 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!\u00a0 Great stuff.<\/p>\n\n
AWSY<\/h3>\n
\n
Leaks Fixed<\/h3>\n
Miscellaneous<\/h3>\n
Generational GC<\/h3>\n