1024062 - Record size of add-on JS compartment in Telemetry

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[:Irving Reid (No longer working on Firefox)]

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.

Comment 1

[Nicholas Nethercote [inactive]]

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 :(

Comment 2

[Emanuel Hoogeveen [:ehoogeveen]]

This is probably a naive suggestion, but is it something we could record *during* GC (while we're iterating the heap anyway)?

Comment 3

[Nicholas Nethercote [inactive]]

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.

Comment 4

[Vladan Djeric (:vladan)]

we could gather these measurements during idle-daily. It's not ideal, but I think we could still get useful numbers out of it

Comment 5

[:Irving Reid (No longer working on Firefox)]

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.

Comment 6

[Nicholas Nethercote [inactive]]

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

Comment 7

[BMO Automation]

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.