implementing memory reporters

Vladimir Vukicevic <[email protected]> Mon, 05 Jan 2009 15:20:16 -0800
Newsgroups gmane.comp.mozilla.performance
Message-ID <[email protected]>
Howdy,

I wrote a simple memory report framework in bug 392351, but 
unfortunately we didn't get around to implementing actual reporters for 
1.9.1.  I've taken a first stab at what some of these could look like, 
in bug 472209.  There's also a simple tool for displaying the data 
attached to that bug -- the output looks something like this: 
http://people.mozilla.com/~vladimir/misc/mem-what.png (ignore some of 
those numbers, that's from an older version of the patch).

Ideally, we'd be able to account for 75% or more of the committed memory 
size of the process -- I don't think we'll ever get to 100% because the 
OS libraries we depend on will always allocate memory underneath us. 
This would give us an idea if any large such allocations are happening 
as well.

I think that this is something that would be best done by the individual 
module owners for their own modules -- they should know best what 
big-ticket allocations should be tracked, as well as knowing what things 
are hard to track.  Per-page tracking would be nice, but not critical 
initially; for some places where we have per page data (e.g. the frame 
arenas) it's not hard to split it out.  Also note that the framework is 
pretty generic -- it can be used to track any numeric value, not just 
memory.  So if it's useful to report the number of some objects, that 
can be done as well.

Is someone willing to step up to be a 'memory owner' for each module, 
responsible for ensuring that memory instrumentation is where it needs 
to be within the module?  Or is there a better approach that we could try?

     - Vlad