Justin Lebar made it so that memory reports could be collected on production B2G phones (i.e. not just developer phones with root access). This was a MemShrink:P1, because getting these reports is crucial.
Gregor Wagner tuned the GC heuristics used by workers. This is important for B2G, which uses workers extensively.
Andrew McCreight fixed a leak involving audio contexts.
I added a memory reporter for event targets, which includes XHRs. This can measure multiple MiB of memory when running Gmail.
I added a memory reporter for data held by the JS engine’s regexp JIT compiler. It usually measures insignificant amounts.
I fixed an inaccuracy in the “resident” memory report tree, which is visible in about:memory when running on Linux, which was caused by a change in recent kernels.
The recent results on AWSY have been ugly. There were two bad regressions in December, as the following graph makes clear.
John Schoenick did some work to improve AWSY to make regression hunting easier, and as a result we finally know which changes caused these regressions.
- A refactoring of images code caused the bigger regression, on December 18. Seth Fowler is looking into this.
- Two changes relating to the new DOM bindings caused the smaller regression on December 11/12. This is largely because many more JS getter/setter functions are present. It’s not clear yet how to win back this memory, though it should be possible to turn these changes off in the short-term.
These regressions have made it to the Aurora branch, which means there is some urgency now to either fix them or back out/disable them soon. We don’t want them to reach Beta.
Here are the current bug counts.
- P1: 21 (-1/+7)
- P2: 125 (-2/+11)
- P3: 104 (-1/+3)
- Unprioritized: 4 (-17/+3)
The changes are larger than usual because we had a big log of untriaged bugs to go through, due to the six week break since the last MemShrink meeting.
11 replies on “MemShrink progress, week 83–84”
Great work guys.
FYI, the AWSY link is broken.
Fixed now, thanks.
For what it’s worth, the long-term plan for the DOM stuff is obvious.
What’s not clear is what, if anything, to do about it in the short term. Turning the quickstubs off is highly undesirable in general, since it leads to the same method/property behaving differently on different HTML elements.
Short-term: just revert what caused the regression, no?
Reverting it would mean a noticeable performance regression and also that different DOM elements would have different behavior for the same method, as I said. Doable, but not desirable.
It might be internally obvious; but it’s not from the outside.
If I had to take a shot in the dark; I’d assume it’s part of the additional record keeping needed to create a generational/compacting garbage collector, but that’s only because I’m not aware of any other major JS projects currently in progress.
Ah, sorry. It’s obvious if you read the bug report, but the bug report wasn’t linked. 😉
The obvious long-term plan is to finish converting all elements to WebIDL, so that there is only one copy of the Element methods/properties instead of one per most-derived *Element prototype.
I can’t tell if you’re being facetious or not; the two bugs njn linked to don’t provide any enlightenment about why the changes were done.
Boris is rarely facetious!
In short, we’re partway through converting a bunch of stuff from one form to another. This part-conversion is causing the memory regression. The proper fix is to finish the conversion.
I’ve just looked at bug 820602 has been fixed which is great news. Is this fix going to land on the Aurora (version 20) and Beta (version 19) channels as well as Nightly?
It will be backported to Aurora 20. It’s not present in Beta 19, so there is no need to do anything there.