Open Bug 1351781 Opened 7 years ago Updated 2 years ago

Stop scheduling full GCs once a minute, unconditionally

Categories

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

50 Branch
enhancement

Tracking

()

People

(Reporter: djvj, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

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.
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.
(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.
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.
Whiteboard: [qf]
Whiteboard: [qf] → [qf:p1]
Blocks: GCScheduling
No longer blocks: 1351769
Whiteboard: [qf:p1]
Not sure about Bug 1376904 as a dep, feel free to re-arrange.
Depends on: 1288177, 1376904
Priority: -- → P5
See Also: → 1673764

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?

(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?)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.