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)
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.
Reporter | ||
Comment 1•9 years ago
|
||
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.
Reporter | ||
Comment 2•9 years ago
|
||
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.
Reporter | ||
Comment 3•9 years ago
|
||
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)
Reporter | ||
Comment 5•9 years ago
|
||
Note to self. The main difficulty will be deallocating these per-Component structures (do we have refcounted pointers in JSAPI?).
Reporter | ||
Comment 6•9 years ago
|
||
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.
Reporter | ||
Comment 7•9 years ago
|
||
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.
Description
•