Reduce non-incremental GCs by increasing the slice budget as we approach the non-incremental threshold
Categories
(Core :: JavaScript: GC, enhancement, P3)
Tracking
()
People
(Reporter: jonco, Assigned: jonco)
References
Details
Attachments
(4 files)
As mentioned in bug 1423065 comment 1. Non-incremental GCs are bad for the user experience so we should try to avoid them. The idea is that at some point before we hit the non-incremental GC threshold we should start increasing the slice budget in such a way that we finish the GC before we reach it. This would add some jank, but not as much as finishing the whole GC non-incrementally.
Updated•7 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
Also, we should start increasing the slice budget if the GC takes too long. Incremental GCs of 25 seconds have been reported. We should aim to keep the time a GC is active for well below that.
Comment 2•6 years ago
|
||
I wonder if you could use the amount of work done in the previous GC to guide how long slice times should be. This doesn't work for the CC because the length varies wildly.
Assignee | ||
Comment 3•4 years ago
|
||
This is less important since bug 1633752 increased the non-incremental limit for small heaps.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
This adds an 'urgent' threshold, which is at a configurable point before we
reach the incremental limit. We calculate how close we are to the limit as a
fraction of bytes remaining until we hit it, giving a value in the range 1 to 0
as we apprach it. Then we increase the slice budget in inverse proportion to
this value, and decreases the allocation threshold for the next slice in
proportion to it.
The value for the urgent threshold is chosen as 16MB since the values for the
incremental limit ratio is chosen so that there is always more than 16MB
between the original GC threshold and the incremental limit. This also allows
the effect to vary from subtle to large over several slices, since alloc
triggered slices are initially 1MB apart.
The calculation is chosen to have no effect at the start (at the urgent
threshold itself), rise slowly but becomes asymptotic as we approach the
incremental limit, with the aim of never reaching this limit.
I couldn't think of a better name than 'urgent threshold'. I think it's
reasonable but it's not very descriptive of how it's used. I'd appreciate any
ideas.
Assignee | ||
Comment 5•3 years ago
|
||
Usually, when an incremental GC is waiting on background tasks to finish we
yield back to the mutator. This patch changes this so that the main thread
blocks until its budget is exhausted in long running GCs where the slice was
triggered by memory allocation. This allows the GC to catch up with the
mutator.
Depends on D120320
Assignee | ||
Comment 6•3 years ago
|
||
Assignee | ||
Comment 7•3 years ago
|
||
Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ac254a6cdfb5 Increase the slice budget and frequency as we approach the incremental GC limit r=sfink https://hg.mozilla.org/integration/autoland/rev/9e4ef9eff490 Ensure GC progress by pausing the mutator in long running GCs r=sfink
Comment 9•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ac254a6cdfb5
https://hg.mozilla.org/mozilla-central/rev/9e4ef9eff490
Updated•3 years ago
|
Description
•