A better about:memory: stage 1.5

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:

GC buttons

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.

On a related note: it’s important that the memory reporters used to generate about:memory be correct, and that the memory be categorized the right way.  (Otherwise you can end up with nonsensical output like the negative numbers I mentioned earlier.)  For example, I just discovered that the JavaScript heap can be allocated on the heap or directly via mmap/VirtualAlloc, depending on whether MOZ_MEMORY is defined or not (see bug 656520).  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”.

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.

about:memory screenshot
Thanks!

7 Responses to A better about:memory: stage 1.5

  1. Very nice, and will be very useful! :)

  2. > 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.

  3. 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.

  4. These changes will land on FF5? I used about:memory in FF5 (Beta channel) but I didn’t see the three buttons.

  5. 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.

    • Nicholas Nethercote

      Doesn’t (re)loading about:memory trigger a garbage collection anyway?

      No. Well, it may, because generating about:memory involves executing some JavaScript, but you can’t rely on it. I usually have to reload it several times to trigger a GC.

      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.