1675153 - Conduct experiment on javascript.options.gc_delay.full

Status: NEW

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

Description

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

When Gecko decides to run a zonal (partial heap) GC, it also schedules a full heap GC at some point in the future, the delay determined by the pref javascript.options.gc_delay.full. Currently, this is set to 60000ms, which is 1 minute. Not all zonal GCs will have a corresponding full GC; if a full GC is already scheduled, no new one will be scheduled.

According to the Nightly results for Fx84, 30% of GCs are zonal (telemetry key GC_IS_COMPARTMENTAL).

I suspect this is excessive, and we could get a perf win from increasing the delay and thereby doing fewer full GCs. The full GCs should not be avoided entirely, since cyclic garbage between collected and uncollected zones will build up from partial GCs. The main risk of delaying these GCs is that we will hold onto more garbage for longer (until the eventual full GC clears it out.)

I would like to do an experiment varying this pref setting to see what improvements we can get.

Comment 1

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

My hypothesis is that if we increase javascript.options.gc_delay.full, then:

• a smaller percentage of GCs will be full GCs (GC_IS_COMPARTMENTAL will decrease)
• we spend less time overall in GCs (GC_MS will decrease)
• there will be more time in between GCs (GC_TIME_BETWEEN_S will increase)
• OOMs will not increase significantly nor substantially
• peak memory usage will increase, but not significantly nor substantially (MEMORY_JS_GC_HEAP)
• pause times might increase, but not significantly nor substantially (GC_MAX_PAUSE_MS_2)

Comment 2

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

The specific values I would like to try are:

• 60000ms (1 minute): the current setting
• 180000ms (3 minutes): a small but fairly safe increase
• 600000ms (10 minutes): a substantial increase such that, if full GCs are causing perf issues, I would expect the costs to largely go away.