1673764 - Reduce frequency of all-zones GCs

Status: NEW

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

Description

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

Right now when we schedule a partial (zonal) GC, we also fire off a 60 second timer to do a full (all zones) GC. If we do another zonal GC while a full GC is pending, we won't queue up another one, but I would expect this to still be a major source of all-zones GCs.

Telemetry on Nightly shows 30% of GCs being all-zones. That seems unnecessarily high to me.

I propose reducing the number of these full GCs. I was thinking of clever heuristics, but honestly all-zones GCs are mostly fallback GCs anyway and it seems like the current setup is pretty reasonable -- if you do a GC, then there's memory activity, so be sure to eventually do a full GC in case there are cycles between zones.

So I'm thinking of increasing the delay from 1 minute to 10 minutes.

Note that I think there are still other reasons why we might choose to do a full GC, so hopefully the timing of this backstop isn't critically important in the cases that need it.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

I wonder if 10min full GC causes issues when running tests.
Could we try first something a bit less radical? 5 mins?
Such change should already change telemetry numbers.

Comment 2

[Jon Coppeard (:jonco)]

(In reply to Olli Pettay [:smaug] from comment #1)

I wonder if 10min full GC causes issues when running tests.

Yes it could. I'd like it if our scheduling handled running tests without resorting to these timed full GCs.

Comment 3

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

Oh. I hadn't realized that these GCs were used for that purpose. Yeah, resolving that somehow seems like a blocker for this, then.

How well do we know why these are needed? Is it that the zones involved don't get scheduled, or they get scheduled early but then never get scheduled again, or what? I have some ideas, but I'm not sure whether they apply to what's going on here.