Tim Taubert set the style of a not-yet-restored tab’s <browser> element to display:none, eliminating the need for any layout data to be stored in memory for such a tab. This was a MemShrink:P1 bug and is a nice improvement for users who typically have many (e.g. 100+) tabs open, because it saves 0.17MB per not-yet-restored tab on 64-bit platforms, and slightly less on 32-bit platforms.
Bobby Holley fixed a defect that was causing some add-ons (NoScript, Roboform, and Google PageSpeed) to create ghost windows. This fix has been also been ported to the Aurora and Beta channels and so will be present in Firefox 16.
Version 1.10 of the Add-on SDK was released. It has two fixes that prevent various leaks. Furthermore, Alexandre Poirot fixed two other leaks in the Add-on SDK; these changes will presumably make it into version 1.11.
The Add-on SDK has had a lot of leaks fixed over the past few months. Hopefully we’re getting near the end of them!
It’s a big task because it makes a very fundamental change to the JS engine: garbage-collected things such as JS objects, strings and functions can move. This is a big deal because these things are represented within the JS engine as C++ objects of various kinds, and it’s not normal for C++ objects to move! Think about it — if you have a pointer to a C++ object, and the object moves, the pointer is no longer valid.
I won’t go into detail about how we handle this but the important thing to know is that pretty much every place in the JS engine where we have a raw C++ pointer to a GC thing object needs to be manually changed to use a new representation. This is literally tens of thousands of changes that must be completed before the garbage collector can be made either compacting or generational (the two properties are orthogonal, with both providing benefits).
If you are interested in following the progress of this conversion, take a look at bug 753203.
In these MemShrink reports I usually write about Firefox changes just after they first land on mozilla-central. Such changes will show up in Nightly builds within a day, but won’t reach an official Firefox release for 12–18 weeks, as per Firefox’s release schedule. If you remember that you’ll avoid any confusion about which changes are in which release.
For example: except where noted otherwise, the changes I’ve mentioned above will be in Firefox 18 — assuming they don’t cause problems that cause them to be backed out — which is due for final release in early January, 2013. (The current scheduled release date is January 1st, but that will probably be delayed slightly because New Year’s Day is not a good day for a release!)
Here are the current bug counts.
- P1: 21 (-1/+0)
- P2: 89 (-5/+4)
- P3: 100 (-3/+7)
- Unprioritized: 3 (-2/+3)