1351781 - Stop scheduling full GCs once a minute, unconditionally

Status: NEW

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

Description

[Kannan Vijayan [:djvj]]

We learned over the last two days that we unconditionally schedule a full GC once a minute.  We should not be doing this blindly, without using any heuristic information at all.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I think bug 1285355 is a dependency here.

Comment 2

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

Isn't that a prerequisite for turning this off completely? I assumed we could drop this way down without fixing bug 1285355, as long as we keep running full GCs occasionally.

Comment 3

[Sean Stangl [:sstangl]]

(In reply to Steve Fink [:sfink] [:s:] from comment #2)
> I assumed we could drop this way down without fixing bug 1285355,
> as long as we keep running full GCs occasionally.

Specifically, we talked about tying full GC scheduling to some form of idle-user detection.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I think the gray bit thing really needs to be fixed. Without it, CCs basically can't free any objects except in the zone that was last collected. The XPConnect thing is less important.

Comment 5

[Florian Bender]

Not sure about Bug 1376904 as a dep, feel free to re-arrange.

Comment 6

[Paul Bone [:pbone]]

The current status of this is that it will schedule a full GC after a previous zonal GC. Is that conditional enough or should we make it more conditional?

Comment 8

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

(In reply to Paul Bone [:pbone] from comment #6)

The current status of this is that it will schedule a full GC after a previous zonal GC. Is that conditional enough or should we make it more conditional?

I noticed this while looking at scheduling too. I think we should try to make it less frequent, if possible.

Right now, if we do a zonal GC, we wait javascript.options.gc_delay.full milliseconds, by default 60000 so one minute, and then run a full GC. One option would be to include idleness -- either immediately starting a full GC when idle, or delaying and then starting a full GC in the next idle period after a minute elapses, or perhaps saying we need to be idle for some length of time before doing the full GC. (And then forcing it to happen sooner if whatever conditions we're waiting for don't arise for too long.)

If there are multiple processes that want to do a full GCs, I'm not sure if they should take turns for the whole GC, or just on a per-slice basis (so if you have 4 processes A-D and they each do 3-slice GCs, the former would run A...A...AB...B...BC...C...CD...D...D and the latter would run ABCD...ABCD...ABCD where the ellipses represent mutator time.) The first option maximizes the chance that each process will stay in cache; the second reduces total wakeups and latency. And I don't know how difficult or expensive such coordination is; perhaps it's not worth coordinating at all (at least, any more than you're already doing, which I think mostly serves to prevent multiple processes from GCing simultaneously and so by itself would give the 2nd option?)