1351800 - Have a "hard" variant for GC timeslices

Status: NEW

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

Description

[Kannan Vijayan [:djvj]]

We don't have a mechanism currently to indicate to the GC during a slice-bound collection, that the timeslice is "hard" - i.e. the GC should err in favour of returning before the timeslice is over, ahead of completing more work.

This would allow us to more confidently schedule time-bound collections when we have a hard limit on the timeslice (e.g. when rendering graphics frames).

Comment 1

[Jon Coppeard (:jonco)]

There are three GC phases where we can overrun the timeslice: root marking, sweeping and compacting.

We can't do anything about the first and I don't think the last is a particular problem so we're mainly talking about sweeping.

The reason this can overrun is that there is currently a whole bunch of work we need to do atomically when we start sweeping a group of zones.  For the first group we already yield beforehand so that this runs with a full slice.  We could add a heuristic to do this for subsequent zones too.

So should this always yield before we start sweeping a new group of zones?  Every zone could be in its own group which would lead to a sweep slice running for every zone, which could make GC take a long time.

Another possibility would be to yield if there was less than a certain amount of our timeslice left, or a certain proportion.  I guess we need data on how long this phase usually lasts (we don't have a separate stats phase for this).

Do we know how long "hard" timeslices are likely to be requested for?  We also need to ensure that GCs don't take forever if the browser is constantly animating.

Comment 2

[Steve Fink [:sfink] [:s:]]

I think the idea here is to add a new tier to our thresholds. The fear is that if we get better about scheduling, so that we're getting more frequent idle callbacks between frames or something, that we might jank more because we have more opportunities to run potentially slow slices.

So I was thinking that we would get pinged with a message saying "now's a good time to do a GC slice, but only if you can keep it under 10ms" or something. If the next slice is a dangerously long one, we would avoid it for a while, but have a threshold at which we decide to go ahead and just do it.

Then again, maybe if we're already trying to do a slice after every frame (NotifyDidPaint), then perhaps this is providing strictly fewer opportunities to GC?

Comment 3

[Steve Fink [:sfink] [:s:]]

This also comes up in the context of Photon, the frontend work to make things faster/smoother, where Ehsan at least would really like a way to postpone GC during important user-visible activity. But if we're sure we can hit our budget, then it ends up squarely under this bug -- "You have 16ms and absolutely no more. Would you like to try to make some progress, or is now not a good time?"

Comment 4

[Steve Fink [:sfink] [:s:]]

Well, ok, you'd also want to stall off the other GC triggers as well. So it wouldn't just be this bug.