System Compartment Reporting
With the recent landing of compartment-per-global, Firefox now regularly has 200+ system compartments at start-up. However, most of these compartments didn’t have names, which meant that they were merged into a single “[System Principal]” entry in about:memory and about:compartments.
Until last week, that is, when Nils Maier added identifying information to the vast majority of these. Here’s a small selection of interesting ones from about:compartments on my own machine.
about:blank about:compartments about:memory?verbose chrome://adblockplus-modules/content/FilterClasses.jsm chrome://browser/content/bookmarks/bookmarksPanel.xul chrome://browser/content/browser.xul chrome://browser/content/places/menu.xml chrome://browser/content/search/search.xml chrome://chatzilla/content/browserOverlay.xul chrome://global/content/bindings/button.xml chrome://global/content/globalOverlay.xul chrome://treestyletab/content/treestyletab.xul file:///home/njn/moz/mi0/o64/dist/bin/components/TelemetryPing.js jar:file:///email@example.com!/bootstrap.js jar:file:///firstname.lastname@example.org!/components/PdfStreamConverter.js resource:///modules/TelemetryTimestamps.jsm resource:///modules/sessionstore/DocumentUtils.jsm resource://gre-resources/hiddenWindow.html resource://gre/modules/AddonManager.jsm resource://services-common/preferences.js resource://services-crypto/WeaveCrypto.js resource://services-sync/constants.js resource://services-sync/engines/bookmarks.js resource://treestyletab-modules/browser.js resource://treestyletab-modules/lib/animationManager.js
Just from this, it’s obvious that I had about:compartments and about:memory?verbose open at the time. It’s also obvious that I had the following add-ons installed: AdBlock Plus, Chatzilla, Tree Style Tab, and pdf.js. And about:memory now gives at least a partial measurement of how much memory these add-ons are using. This will help identify add-ons that are using excessive amounts of memory. (Having said that, I identified the add-on compartments simply by their names. It’d be great if there was a way to systematically identify them within the code, but I don’t know if that’s possible.)
I also hope people will scrutinize Firefox’s own compartment use closely, and start to file bug reports saying things like “hey, that .jsm module shouldn’t be present, there must be a leak”. If you want to see what the full list of 200+ looks like, try out a recent Nightly build!
In related news, I also added some new compartment-specific reports, including ones for cross-compartment wrappers.
One consequence of all these change is that the number of entries in about:memory jumped tremendously. As a result, I aggregated the small entries within each compartment, which reduces the number of entries by a factor of roughly four while still reporting full information for large compartments. Nils and I also made about:memory more efficient, so the amount of memory required to generate each line dropped by about 20%. about:memory still takes up memory itself, but it does so at a level that I’m fairly happy with.
For a change, the biggest MemShrink-related news in this report wasn’t related to add-ons! But there was still some interesting movement there.
Justin Lebar uncovered some evidence that the Hueyfix is having a real, positive effect among users. Telemetry data from Nightly users shows that the number of ghost windows — a concept for which we don’t have good documentation, but they correlate with zombie compartments — has dropped dramatically, as the following graph shows.
Telemetry data tends to be extremely noisy, so it’s nice to see a clear signal — Kyle’s change made it into Nightly builds on May 5th [Update: that’s incorrect, see below] and immediately caused the mean number of ghost windows to drop from roughly three to roughly one. The variance also dropped dramatically.
Update: Justin just wrote a blog post that explains very nicely what ghost windows are. That post also explains better the circumstances behind the drop in ghost window numbers; my explanation above was too simple and got the timing wrong. Thanks, Justin!
Firefox vs The New York Times
Robert O’Callahan fixed a leak relating to mouse events that triggered when he visited nytimes.com. He wrote a great blog post explaining the heroic debugging — searching through full memory dumps! — that was required. It’s great that Robert found and fixed this, though it’s a shame it took such expertise.
Here are the current bug counts.
- P1: 23 (-1/+2)
- P2: 85 (-2/+4)
- P3: 102 (-5/+2)
- Unprioritized: 2 (-3/+2)
Not a great deal of movement. We only had to triage twelve bugs in today’s MemShrink meeting, which is the fewest we’ve had since we switched to fortnightly meetings.