Closed Bug 1434542 Opened 4 years ago Closed 2 months ago

Reduce non-incremental GCs by increasing the slice budget as we approach the non-incremental threshold

Categories

(Core :: JavaScript: GC, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox60 --- wontfix
firefox92 --- fixed

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.
Severity: normal → enhancement
Priority: -- → P3
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.
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.
Blocks: 1579426

This is less important since bug 1633752 increased the non-incremental limit for small heaps.

No longer blocks: 1579426
See Also: → 1579426
Blocks: 1721168
Assignee: nobody → jcoppeard

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.

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

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
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
Regressions: 1721838
Regressions: 1724510
You need to log in before you can comment on or make changes to this bug.