Inspired by Shaver’s patch, I implemented some per-compartment stats in about:memory. I then visited TechCrunch because I know it stresses the JS engine. Wow, there are over 70 compartments! There are 20 stories on the front page. Every story has a Facebook “like” button, a Facebook “send” button, and a Google “+1” button, and every button gets its own compartment.

That sounds like a bug, but it’s probably not. Nonetheless, every one of those buttons had an entry in about:memory that looked like this:

(The ‘object-slots’ and ‘scripts’ and ‘string-chars’ measurements are also new, courtesy of bug 571249.)

Ugh, 255,099 bytes for a compartment that has only 971 bytes (i.e. not much) of scripts? Even worse, this is actually an underestimate because there is another 68KB of tjit-data memory that isn’t being measured for each compartment. That gives a total of about 323KB per compartment. And it turns out that no JIT compilation is happening for these compartments, so all that tjit-data and mjit-code space is allocated but unused.

Fortunately, it’s not hard to avoid this wasted space, by lazily initializing each compartment’s TraceMonitor and JaegerCompartment. With that done, the entry in about:memory looks like this:

That’s an easy memory saving of over 20MB for a single webpage. The per-compartment memory reporters haven’t landed yet, and may not even land in their current form, but they’ve already demonstrated their worth. You make what you measure.