1352524 - (GCScheduling) [meta] Improve GC scheduling

Status: NEW

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

Description

[Kannan Vijayan [:djvj]]

This bug has been created after investigations and discussion with several people.

Garbage collection spans both the spidermonkey engine as well as gecko.  There is very little in the way of central decision making.

For example, we unconditionally schedule a full GC once every minute.  Spidermonkey independently schedules GC when under malloc pressure.  And various other garbage collections are scheduled heuristically (e.g. GC after tab close).

These decisions need to be made centrally, taking into account all inputs, including:

1. Recentness of user activity
2. Whether we have recently spent a long time in JS (i.e. jank)
3. Whether the user just initiated an activity that requires smooth UI (don't GC in the middle of that).
4. Malloc pressure
5. System memory availability
6. Estimated next time that a particular event queue will become active (estimate using timeout events).

Comment 1

[Kannan Vijayan [:djvj]]

This bug _may_ subsume some of the other bugs under the QFGC meta bug 1351769 (e.g. the per-minute full GC invocation in bug 1351781).

Comment 2

[Kannan Vijayan [:djvj]]

I suggest a general plan of action:

1. A quick but complete survey of all the places in the codebase where a GC can get invoked, and an understanding of how that invocation could occur (i.e. what user actions or browser circumstance leads to the invocation), and an understanding of the kinds of GCs that can be invoked at those locations.

2. Characterize the issue that each of those is trying to address (i.e. why does that location feel a need to do a GC at that time, and what's the expected positive outcome?)

3. For each of those "gc motivations", figure out what inputs need to feed into the decision on when and if to invoke a GC, and if so what kind.

4. Collect all of these together and build a model that explain: what inputs are coming in to the scheduler, and how the scheduler uses those inputs to make scheduling decisions that speak to the motivations described in point 3.

Comment 3

[Till Schneidereit [:till]]

CC Servo people

Comment 4

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

One thing to remember is that we used to take user activity into account more, but that was bad heuristic, so it got removed.
Though, that was during the single process FF era.

Comment 5

[Jon Coppeard (:jonco)]

This will have to decide both when to trigger a new incremental GC, and when to schedule the next slice of an ongoing incremental GC.

Also, I think cycle collection will need to be scheduled from the same mechanism to have a coordinated system.

Comment 6

[Andrew McCreight [:mccr8]]

(In reply to Jon Coppeard (:jonco) from comment #5)
> Also, I think cycle collection will need to be scheduled from the same
> mechanism to have a coordinated system.

Yes, this is definitely true. We can't run IGC and ICC at the same time, so if we decide to run one when the other is already in progress then we have to sync finish it, which is bad.

It will also need to decide how long a slice is. Ideally, we would make slices longer if we are falling behind, again to prevent a sync finishing off of the collection.

Comment 7

[Sean Stangl [:sstangl]]

Taking bug, since I'm looking into this.

Currently I'm looking into first creating timing for the XPCOM event loop re-entry. The situation is a little complicated since there seem to be multiple points that should be considered "the event loop". If that timing information is then passed on to the GC, it could use that timing information to make a decision, even without a "scheduler".

As far as a "scheduler", it would probably be implemented as an Event that gets scheduled normally, but then determines whether or not to actually take action at the point of running.

Comment 8

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

FWIW, I'm also looking at to use idle time for CC and GC timers which nsJSEnvironment has.