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
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance
