GCRuntime::checkHeapThreshold unlikely to trigger non-incremental GCs, because it multiplies thresholdBytes with itself
Categories
(Core :: JavaScript: GC, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox70 | --- | wontfix |
firefox71 | --- | fixed |
firefox72 | --- | fixed |
People
(Reporter: anba, Assigned: jonco)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
size_t niThreshold = thresholdBytes * tunables.nonIncrementalFactor();
if (usedBytes >= thresholdBytes * niThreshold) {
// We have passed the non-incremental threshold: immediately trigger a
// non-incremental GC.
return TriggerResult{TriggerKind::NonIncremental, usedBytes, niThreshold};
}
thresholdBytes * niThreshold
in the if-condition looks wrong, because that's thresholdBytes * thresholdBytes * tunables.nonIncrementalFactor()
. The correct condition should most likely be usedBytes >= niThreshold
.
Assignee | ||
Comment 1•6 years ago
|
||
Nice catch. I broke this while refactoring in bug 1570905.
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
Fix a mistake calculating the heap size to compare against. It's unlikely this bug had much effect because whether to perform an incremental or non-incremental collection is decided when we start the collection in GCRuntime::budgetIncrementalGC().
Comment 4•6 years ago
|
||
bugherder |
Comment 5•6 years ago
|
||
Sounds like this fix can ride the trains given comment 2, but feel free to nominate for Beta approval if you feel otherwise.
Assignee | ||
Comment 6•6 years ago
|
||
Comment on attachment 9104683 [details]
Bug 1591711 - Fix incorrect calculation of non-incremental GC trigger r?sfink
Beta/Release Uplift Approval Request
- User impact if declined: This change seems to have reduced the number of GC resets (From ~0.38% to ~0.1% on beta) The occurrence is still very low but this is such a simple fix it may be worth taking anyway. The user impact would be slightly less chance of jank due to GC.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a very simple fix that returns a GC trigger calculation to its original state.
- String changes made/needed: None
Comment 7•6 years ago
|
||
Comment on attachment 9104683 [details]
Bug 1591711 - Fix incorrect calculation of non-incremental GC trigger r?sfink
Low risk, has tests and was on beta for a week, uplift approved for 71 beta 8, thanks.
Comment 8•6 years ago
|
||
bugherder uplift |
![]() |
||
Updated•6 years ago
|
Updated•4 years ago
|
Description
•