Lots of changes were made to about:memory this week.
Justin Lebar landed a patch that provides detailed information about RSS, vsize and swap memory usage on Linux and Android. (The patch was backed out due to a minor leak but I expect Justin will fix that and re-land it soon.) This will help us understand memory usage that is not covered by the “Explicit Allocations” tree in about:memory, such as memory used for static code and data, and it should be particularly useful on Android. The contents of the new trees are hidden by default; you have to click on the tree heading to expand each one.
Kyle Huey split up about:memory’s layout measurements on a per-PresShell basis. This makes it easy to see how much layout memory is being used by each web page.
moz_malloc_usable_size to measure actual allocation sizes instead of requested allocation sizes. This accounts for slop bytes caused by the heap allocator rounding up. This is quite important — slop bytes can easily account for over 10% of the heap, and if we don’t account for them we’ll never get about:memory’s “heap-unclassified” number down. Therefore I’ll be doing more of this in the future. And it would be great if people writing new memory reporters can do the same thing!
Finally, on the topic of “heap-unclassified” number: people often complain about it, so I’m happy to say that it is on a clear downward path. Indeed, thanks to DMD, at the time of writing we have 16 open bugs to add new memory reporters for things that consume significant amounts of memory, and 13 of these are assigned. I’m hoping that in a month or two the “heap-unclassified” number on development builds will typically be 10–15% rather than the 30–35% it usually is now.
I changed the growth strategy used for one of JaegerMonkey’s buffers to avoid large amounts of memory wasted due to slop bytes. These buffers are short-lived so the fix doesn’t make a great difference to total memory consumption, but it does reduce the number of allocations and heap churn.
Marco Bonardo wrote about his recent changes to the handling of the places database.
Dietrich Ayala wrote about an experimental add-on that unloads tabs that haven’t been viewed in a while, which is an interesting idea. I suspect the exact approach used in the add-on won’t be viable in the long run, but we can certainly benefit from doing a better job of discarding regenerable info that hasn’t been used in a while, particularly on mobile.
This weeks’s bug counts are as follows:
- P1: 29 (-2, +2)
- P2: 80 (-4, +8)
- P3: 40 (-2, +4)
- Unprioritized: 22 (-12, +12)
Just like last week, Marco Castelluccio tagged quite a lot of old bugs with “[MemShrink]”. We had 45 unprioritized bugs at the start of this week’s meeting, and we got through more than 20 of them.
Some comments on last week’s post got me thinking about how to make it easier for more people to help with MemShrink. For those who don’t have much coding experience, probably the best bet is to look at the list of unconfirmed bugs — these are problems reported by users where the particular problem hasn’t been identified. Often they need additional effort to determine if they are reproducible, due to add-ons, etc. For example, in bug 676872 a user was seeing very high memory usage, and it’s clear that it was caused by one or more of the 41(!) add-ons he had enabled. Ideally that bug’s reporter would disable them selectively to narrow that down, but anyone could do likewise with some effort.
For those who do have coding experience, it would be worth looking at the list of bugs that have a “mentor” annotation. For example, bug 472209 is about adding some graphing capability to about:memory. Jezreel Ng made some excellent progress on this during his internship, it just needs someone to take over and finish it up.
Finally, for those who like a challenge or have some experience with Firefox’s code, the full list of unassigned bugs might be of interest. There are currently 86 such bugs! More than I’d like.
(BTW, I’ve added links for the three bug lists above to the MemShrink wiki page.)
I will be on vacation for the next five weeks and the MemShrink progress report will be on hiatus during that time. But MemShrink meetings will continue (except there won’t be one next week due to the Mozilla all-hands meeting). I look forward to writing a bumper progress report on October 19, where I’ll be able to summarize everything that happened while I was away!