I just landed a bunch of changes to about:memory (bug 648490, bug 653630, bug 654041, bug 655638, bug 655583). Mostly they just fix some minor problems; if you’ve seen negative numbers in about:memory since the revamp hopefully you won’t any more! (Please tell me or file a bug if you do.)
But there’s one cool new feature:
At the bottom of about:memory there are now three buttons. Here are the “title” attributes for each one, which show up as tool-tips if you hover your mouse over them, and explain what they do.
- GC: Do a global garbage collection.
- GC + CC: Do a global garbage collection followed by a cycle collection. (It currently is not possible to do a cycle collection on its own, see bug 625302.)
- Minimize memory usage: Send three “heap-minimize” notifications in a row. Each notification triggers a global garbage collection followed by a cycle collection, and causes the process to reduce memory usage in other ways, e.g. by flushing various caches.
As far as I know this is the first time users have been able to trigger GC and CC easily in a vanilla browser. It’ll be particularly useful when analyzing memory usage, e.g. trying to determine if there’s a leak. Often in that case you want to trigger a GC and/or CC to make sure that the memory stats aren’t currently inflated by dead objects, and it’s now really easy to do so.
I’ve checked all the reporters as best as I can. I’m pretty confident now that all the JS and storage (SQLite) reporters are correctly categorized as “heap” or “mapped”. I’ve looked at the others and I think they’re right, but I’m not totally certain. More specifically, the reporters in the following screenshot are currently categorized as “heap” (i.e. allocated with oe of: malloc, calloc, realloc, posix_memalign, operator new, operator new). If anyone knows that to be false, I’d love to hear about it. In particular, I’m worried about image-related memory that might be stored in video RAM; I already adjusted two reporters (gfx-2d-surfacecache and gfx-2d-surfacevram) for this reason.
7 replies on “A better about:memory: stage 1.5”
Very nice, and will be very useful! 🙂
> On Mac, MOZ_MEMORY is not defined (because it currently doesn’t use jemalloc) and so the GC heap was incorrectly being categorized under “Used Heap Memory” instead of the “Mapped Memory”.
Unsupported platforms like Win64 also don’t have jemalloc support, so I guess there this applies too.
What would be cool is if you can add the ability to get more detailed info about the sqlite tables + the ability to vacuum them.
These changes will land on FF5? I used about:memory in FF5 (Beta channel) but I didn’t see the three buttons.
Rapier: they won’t be in FF5. They will be in FF6, barring disaster.
Doesn’t (re)loading about:memory trigger a garbage collection anyway?
Another thing, is the output easily copy/pastable now? Because in 4.0(.1) it isn’t.
It cut and pastes very nicely now. See http://blog.mozilla.org/nnethercote/2011/05/02/a-better-aboutmemory-stage-1/ for details.