Are we slim yet?
This is a major milestone for the MemShrink project. It shows the progress we have made (MemShrink started in earnest in June 2011) and will let us identify regressions more easily.
John’s done a wonderful job implementing the site. It has lots of functionality: there are multiple graphs, you can zoom in on parts of graphs to see more detail, and you can see revisions, dates and about:memory snapshots for individual runs.
John has also put in a great deal of work refining the methodology to the point where we believe it provides a reasonable facsimile of real-world browsing; please read the FAQ to understand exactly what is being measured. Many thanks also to Dave Hunt and the QA team for their work on the Mozmill Endurance Tests, which are at the core of AWSY’s testing.
Update: Hacker News has reported on this.
window objects) can also be leaked, and often defects that cause compartments leaks will cause window leaks as well.
Justin Lebar has introduced the notion of “ghost windows”. A ghost window is one that meets the following criteria.
- Shows up in about:memory under “window-objects/top(none)”.
- Does not share a domain name with any window under “window-objects/active.
- Has met criteria (1) and (2) for a moderate amount of time (e.g. two minutes).
The basic idea is that a ghost window has a high chance of representing a genuine leak, and this automated identification of suspicious windows will make leak detection simpler. Justin has added ghost window tracking to about:memory, about:compartments, and telemetry. (These three bugs were all marked as MemShrink:P1.) Ghost window tracking is mostly untested right now, but hopefully it will become another powerful tool for finding memory leaks.
We’ve been tracking leaky add-ons in Bugzilla for a while now, but we’ve never had a good product/component to put them in. David Lawrence, Byron Jones, Stormy Peters and I have together created a new “Add-ons” component under the “Tech Evangelism” product. The rationale for putting it under “Tech Evangelism” is that it nicely matches the existing meaning of that phrase — it’s a case where a non-Mozilla entity is writing defective code that interacts with Firefox and hurts users’ experiences with and perceptions of Firefox, and Mozilla can only inform, educate and encourage fixes in that defective code. This component is only intended for certain classes of common defects (such as leaks) that Mozilla contributors are tracking. It is not intended for vanilla add-on bugs; as now, they should be reported through whatever bug-reporting mechanism each add-on uses. I’ve updated the existing open bugs that track leaky add-ons to use this new component.
This week’s bug counts:
- P1: 21 (-5/+0)
- P2: 137 (-1/+7)
- P3: 90 (-1/+3)
- Unprioritized: 1 (-1/+1)
Good progress on the P1 bugs!
A new reporting schedule
Many of the weekly MemShrink reports lately have been brief. From now on I plan to write a report every two weeks. This will make things easier for me and will also ensure each report is packed full of interesting things. See you again in two weeks!