Regression in GC_BUDGET_OVERRUN in January
Categories
(Core :: JavaScript: GC, defect)
Tracking
()
People
(Reporter: bas.schouten, Unassigned)
References
Details
It looks like GC_BUFFER_OVERRUN regressed in January: https://glam.telemetry.mozilla.org/firefox/probe/gc_budget_overrun/explore?currentPage=1&timeHorizon=ALL
We see the regression on all branches for 124.
Olli suggested this may be related to https://hg.mozilla.org/mozilla-central/rev/1051cef25fba or https://hg.mozilla.org/mozilla-central/rev/859c538033a5d0fc06c7012735e981cdb099d476
75th percentile of max pause seems to have improved around that same time, which is obviously a good thing: https://glam.telemetry.mozilla.org/firefox/probe/gc_max_pause_ms_2/explore?currentPage=1&timeHorizon=ALL
As has total GC time: https://glam.telemetry.mozilla.org/firefox/probe/gc_ms/explore?currentPage=1&timeHorizon=ALL
|
||
Comment 1•1 year ago
|
||
Max pause time could be close to 50ms without causing any issues, since that is the max idle time. It is hard to say whether lowering max pause time is a good thing. It may or may not. If we can run most of the GCs faster, it is a good thing, but if we still have lots of slices, it would be good if we could find long 50ms slices for them.
|
||
Comment 2•1 year ago
|
||
Likely due to parallel marking being enabled and the extra overhead of thread synchronisation at the end of a slice.
There are proportionally large increases for 75th percentile and below, but note that this is measured in microseconds. The 75th percentile has risen to 92 microseconds on a budget measured in milliseconds (median is around 20mS). So I don't think this is a big deal.
|
|
||
Comment 3•1 year ago
|
||
Closing this as wontfix.
Description
•