Closed Bug 1024062 Opened 9 years ago Closed 5 years ago
Record size of add-on JS compartment in Telemetry
When bug 990729 lands, we'll have fairly accurate information about the amount of memory consumed by add-ons. We should add this info to the add-on details Telemetry section so that we can identify memory-heavy add-ons. We probably want to show the info as a % of total memory consumed, but Telemetry should probably transmit actual amounts and calculate the % in the back end.
It's a nice idea but there's a big problem with it: telemetry measurements need to be quick, and compartment measurements aren't always quick, because they require iterating over every cell on the GC heap. And this happens on the main thread. We used to do for the whole heap but eventually stopped because it caused pauses for enough people that it was a problem. Therefore I'm reluctant to head down that path again :(
This is probably a naive suggestion, but is it something we could record *during* GC (while we're iterating the heap anyway)?
The iteration done by memory reporting is a linear scan through the GC heap, and it touches every cell, even ones that might be dead. The "iteration" done by GC is very different; it jumps around all over the place while visiting just the live cells. It might be possible to measure at the same time, so long as you're careful not to measure anything twice, though it would be quite a change from the current code. And measuring all the malloc'd blocks that hang off GC cells could slow down the GC step quite a bit. Overall, it might be feasible... not sure.
we could gather these measurements during idle-daily. It's not ideal, but I think we could still get useful numbers out of it
Took a quick look and didn't see any telemetry on how long the various steps in about:memory take; it would be interesting to gather some data on that to know what kind of jank we'd suffer. I suspect idle-daily is too unreliable for our purposes, but we could do "idle at least N seconds, and at least M minutes since the last time we sampled" easily enough.
(In reply to :Irving Reid from comment #5) > Took a quick look and didn't see any telemetry on how long the various steps > in about:memory take; it would be interesting to gather some data on that to > know what kind of jank we'd suffer. We have TELEMETRY_MEMORY_REPORTER_MS for the telemetry memory measurements that are already present -- in Nightly 32 the median is 27ms and the 95th percentile is 76ms -- but that doesn't tell us anything about the additional measurements being proposed. We don't have any telemetry probes for how long compartment measurements take.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.