Testcase spends 14 seconds in nsAtomSubTable::GCLocked(GCKind) on reloading it in a background tab
Categories
(Core :: XPCOM, defect)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
Details
Attachments
(1 file)
|
2.93 KB,
text/html
|
Details |
Open the attached testcase
Click on Generate
Wait for the checkboxes to be geenrated
Open a new tab and switch to it (making it the foreground tab)
Reload the original tab (in the background tab)
Wait for the CPU use in the background tab to stop.
3000000 checkboxes: Profile: https://share.firefox.dev/4jnvkFF
Maybe something to improve?
|
Reporter | |
Comment 1•26 days ago
•
|
||
On a build from Jan2022, this time is labelled as Free snow-white. So this bug may very well be a CC bug.
No idea how real-world this is. Feel free to WONTFIX/INVALID.
|
||
Comment 2•24 days ago
|
||
Andrew, do you have thoughts about this?
|
||
Comment 3•24 days ago
|
||
(In reply to Mayank Bansal from comment #1)
On a build from Jan2022, this time is labelled as Free snow-white. So this bug may very well be a CC bug.
Free snow white is just how cycle collected things show up when they are being destroyed. It doesn't have anything to do with the CC directly.
|
|
||
Comment 4•24 days ago
|
||
From the profile, it looks like this test case is generating a large number of XPCOM atoms. Maybe this is hitting some kind of quadratic behavior? It looks like we GC this atom table every so often (every 10,000 destroyed atoms) but clearly that's too often for this test case. Maybe the threshold should be more proportional to the size of the table, or maybe if we're doing an operation like UnbindFromTree that might destroy a lot of atoms we want to disable the GCing entirely and then do a single check when we're done?
From the commits, it looks like a lot of effort has been put into speeding up XCPOM atom GCing already, maybe for Stylo, so it doesn't feel to me like we should try to improve this unusual test case as it could cause problems for other more common uses.
|
||
Comment 6•19 days ago
|
||
comment 4 seems accurate. This is creating a massive atom table, and then GC-ing it very often which is linear with the amount of atoms.
Adding a dynamic threshold based on the total atom count is probably the best way to deal with this, but then again that causes us to keep track of all the atoms around, not just the unused ones...
Another potential thing to do is to move the non-shutdown atom table gc to a non-main-thread. That could still have some contention if the main thread tries to atomize stuff while the GC happens, but it is probably better and lower effort...
Moving to xpcom because you can create this situation with other similar things like class attributes (or really anything that gets atomized).
Description
•