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

Status: RESOLVED FIXED

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

Description

[Jon Coppeard (:jonco)]

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.

Comment 1

[Jon Coppeard (:jonco)]

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

[Andrew McCreight [:mccr8]]

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.

Comment 3

[Jon Coppeard (:jonco)]

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

Comment 4

[Jon Coppeard (:jonco)]

Attachment: Bug 1434542 - Increase the slice budget and frequency as we approach the incremental GC limit r?sfink

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.

Comment 5

[Jon Coppeard (:jonco)]

Attachment: Bug 1434542 - Ensure GC progress by pausing the mutator in long running GCs r?sfink

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

Comment 6

[Jon Coppeard (:jonco)]

Attachment: Profiler screenshot of a long running GC without the patches in the bug. The GC concludes with a long final slice of 145ms as we've reached the incremental limit.

Comment 7

[Jon Coppeard (:jonco)]

Attachment: Profiler screenshot of a long running GC with the patches in this bug. This shows increased slice buget. Now the max pause is only 20ms.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
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

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/ac254a6cdfb5
https://hg.mozilla.org/mozilla-central/rev/9e4ef9eff490