Up until this week, about:memory was a static pages; once generated, it couldn’t change. This week, I landed a patch that makes every sub-tree expandable and collapsible. This can be quite useful, because it gives you fine control over what details to ignore. The following screenshot shows an example where all the level 1 sub-trees in the “explicit” tree are collapsed except for “startup-cache”. (
++ indicates sub-trees that can be expanded,
-- indicates sub-trees that can be collapsed, and the remaining nodes (such as “heap-unclassified”) are leaf nodes).
I also changed about:memory so that obviously bogus values (e.g. negative values, percentages greater than 100%) are highlighted. These indicate bugs in memory reporters, and so we want to know about them.
I added new memory reporters for style sheets. This was the single biggest remaining chunk of dark matter. On a 64-bit Linux build, this reduces the “heap-unclassified” count when I have Gmail and TechCrunch open from ~23% to ~15%. The counts mostly show up under the “explicit/dom+style” sub-tree, in “style-sheets” leaf nodes.
I also simplified the writing of memory reporters by removing the need for the
computedSize argument when measuring the size of a heap block.
Finally, if you create a sandbox with
Components.utils.Sandbox, you can specify a name and about:memory will use that name to identify the sandbox’s compartment. Sander van Veen made it so that sandboxes that aren’t given a name will use the their callers’ filename as a name. In other words, all sandboxes should now be identifiable in about:memory.
Brian Hackett fixed a leak in JaegerMonkey.
I mentioned last week that I think leaky add-ons are the #1 problem for Firefox’s memory consumption, and mentioned the idea of telling users when they have an add-on installed that is known to have performance problems. Bug 720856 is open for this. Asa Dotzler, Firefox Product Manager, said:
I will secure Firefox client developer resources for this feature where I have some input into resourcing. If this plan is deemed appropriate, I will work with Justin to secure AMO side resources as well and we can nail this problem.
We can’t keep going back and forth on this while our users suffer. We must act now. I understand that defining “bad add-ons” will be contentious but so long as the technical approach is righteous we can sort out how heavy handed we want to be on policy at a later time and move forward implementing this today.
There was already a feature page covering this basic idea, and Asa updated it. This feature would be a huge help to users. Fingers crossed we’ll see some progress soon!
Henrik Skupin has started working on an add-on called MemChaser (download it here) which is aimed at helping detect problems relating to memory consumption. Currently it just shows some stats in the add-on bar — resident memory consumption (updated every two seconds), how long the last garbage collection took, and how long the last cycle collection took — but Henrik has many ideas for the future. Worth watching!
Here are this week’s bug counts.
- P1: 22 (-0/+2)
- P2: 130 (-3/+2)
- P3: 74 (-2/+2)
- Unprioritized: 3 (-4/+3)