Bug 918207 adds a fast per-tab memory reporter. Based on that, it'd be great to enable collecting memory profiles per-tab or, if possible, per-compartment. Something like `performance.takeMemoryProfile()`. Per-compartment, this might be safe enough to just enable[1]. For the per-tab version, it could be enabled (per location?) in the devtools and just return some default value otherwise. Or, it could log the result to the console, without the content script getting to it. The important part is that content script has the domain knowledge required to make sensible decisions about when to take such a profile. For use in Shumway, I wrote a tiny addon that just returns the current RSS value: https://builder.addons.mozilla.org/package/204025/latest/ Not only is this slow, it also will break as soon as we go to e10s, and already won't work on mobile. Also, it only gives one value, whereas bug 918207 adds a more-detailed profile. [1]: tc39 is entertaining the thought of adding WeakRefs, which would make GC timing visible to script[2] [2]: http://wiki.ecmascript.org/doku.php?id=strawman:weakreferences

Chrome has something like this called performance.memory. They talk about it a bit here: http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/ They do things like quantize and rate limit the values that are returned: https://bugs.webkit.org/show_bug.cgi?id=80444 https://bugs.webkit.org/show_bug.cgi?id=86636 So, it would be good to take a look at what they are doing, and probably get some kind of security review.

Very interesting. I wonder if we could get by without the quantization and rate limiting by restricting this to the current compartment. Within a compartment, I don't see why we shouldn't assume that the code has full (theoretical, at least) knowledge about its object graph. Ocap solutions could censor performance.memory. I'll look into whether I can prototype this with an addon. I *think* we have that information accessible to xpcom.

Oh, and especially the rate limiting would be very nice to get rid of. "[C]ompar[ing] memory usage before and after some event" is precisely what I'd be most interested in. Maybe having performance.memory with roughly Chrome's features and performance.localMemory or something with detailed per-compartment information might work.

Bug 918207, as currently coded, is very much oriented around tabs, not compartments. You pass the special JS function a |window| and it gives you: (a) the JS memory consumption for that window's zone, and (b) the non-JS (e.g. DOM, style, layout) memory consumption for that window and its children. Because lots of stuff (most notably strings) are stored per-zone rather than per-compartment, I don't think per-compartment profiling is useful.

That's a very good point I hadn't thought about. Even worse, we also have per-runtime stuff, such as script bytecode. I don't know how important that is for the usecases here, but it is another wrinkle. With these things in mind, we'll have to do something similar to what Chrome does, I guess. It'd be very nice to be able to remove the rate limiting and quantization via the devtools, though.

If this is going to be exposed to content, it probably needs to go through some standards body. Either way, I don't think this bug belongs in this component.