{"id":1311,"date":"2011-09-07T17:25:20","date_gmt":"2011-09-07T06:25:20","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1311"},"modified":"2011-09-07T17:25:20","modified_gmt":"2011-09-07T06:25:20","slug":"memshrink-progress-week-12","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2011\/09\/07\/memshrink-progress-week-12\/","title":{"rendered":"MemShrink progress, week 12"},"content":{"rendered":"

about:memory improvements<\/h3>\n

Lots of changes were made to about:memory this week.<\/p>\n

Justin Lebar landed a patch that provides detailed information about RSS, vsize and swap memory usage on Linux and Android<\/a>.\u00a0 (The patch was backed out due to a minor leak but I expect Justin will fix that and re-land it soon.)\u00a0 \"\"<\/a> 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.\u00a0 The contents of the new trees are hidden by default;\u00a0 you have to click on the tree heading to expand each one.<\/p>\n

Kyle Huey split up about:memory’s layout measurements on a per-PresShell basis<\/a>.\u00a0 This makes it easy to see how much layout memory is being used by each web page.<\/p>\n

\"\"<\/a><\/p>\n

Something I failed to mention last week <\/a>was that with the landing of type inference, each JavaScript compartment has five new measurements: “object-main”, “script-main”, “tables”, “analysis-temporary”, and “object-empty-shapes”.<\/p>\n

\"\"<\/a><\/p>\n

I converted some of the JavaScript memory reporters to use moz_malloc_usable_size<\/code> to measure actual allocation sizes instead of requested allocation sizes.\u00a0 This accounts for slop bytes caused by the heap allocator rounding up.\u00a0 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.\u00a0 Therefore I’ll be doing more<\/a> of this<\/a> in the future.\u00a0 And it would be great if people writing new memory reporters can do the same thing!<\/p>\n

Finally, on the topic of “heap-unclassified” number:\u00a0 people often complain about it, so I’m happy to say that it is on a clear downward path.\u00a0 Indeed, thanks to DMD<\/a>, at the time of writing we have 16 open bugs to add new memory reporters<\/a> for things that consume significant amounts of memory, and 13 of these are assigned.\u00a0 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.<\/p>\n

Other things<\/h3>\n

I changed the growth strategy used for one of JaegerMonkey’s buffers<\/a> to avoid large amounts of memory wasted due to slop bytes.\u00a0 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.<\/p>\n

Marco Bonardo wrote about his recent changes to the handling of the places database<\/a>.<\/p>\n

Dietrich Ayala wrote about an experimental add-on that unloads tabs that haven’t been viewed in a while<\/a>, which is an interesting idea.\u00a0 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<\/a>, particularly on mobile.<\/p>\n

Bug counts<\/h3>\n

This weeks’s bug counts are as follows:<\/p>\n