Closed Bug 1137522 Opened 9 years ago Closed 9 years ago

Avoid double-counting total time spent in each compartment

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 674779

People

(Reporter: Yoric, Unassigned)

References

Details

Bug 674779 introduces per-compartment CPU usage.

Unfortunately, time can be charged several times to the same add-on, e.g.: if compartment A calls (directly or indirectly) compartment B, and both A and B belong to the same add-on, the user (respectively system) time spent in B will be charged to both A and B's totalUserTime (respectively totalSystemTime). If we simply sum up A and B's `totalUserTime`s, this time will be counted twice.
Probably slow method: put in a hashtable all the `addonId` of all the addons currently on the stack. Use that information to avoid double-counting `totalUserTime`.

Unfortunately, this means that the `totalUserTime` for compartment B will be short-changed.
I believe that I have a faster, more exact way.

We define Component as follows: all the compartments of a single add-on are a single Component, all the built-in compartments of Firefox taken together are a single Component, and each webpage is a single Component. We wish to compute the systemTime and userTime of each Component, which is generally more meaningful than that of each compartment.

To do this, we attach to each compartment a (lazily instantiated) pointer to a per-runtime, per-Component structure holding the Component's systemTime and userTime. These values are updated only by the topmost JSAutoStopwatch for an addon.

Also, orthogonally, to simplify CPU% calculation and avoid double-counting there, we should probably store the topmost systemTime/userTime somewhere.
Also, I believe that we are much more interested in per-Component systemTime/userTime than in per-compartment systemTime/userTime, so I believe that we should by default compute only the per-Component value, and add the per-compartment value only if some preference is set.

Brad, does that seem ok to you?
Flags: needinfo?(blassey.bugs)
I think that's exactly what we should do.
Flags: needinfo?(blassey.bugs)
Note to self. The main difficulty will be deallocating these per-Component structures (do we have refcounted pointers in JSAPI?).
Apparently, no refcounted pointers in JSAPI. I'll have to roll out my own, but that's probably easier than I initially thought, given the simplicity of the data structure involved.
This ended up being implemented in bug 674779.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.