Open Bug 1352524 (GCScheduling) Opened 7 years ago Updated 11 months ago

[meta] Improve GC scheduling

Categories

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

50 Branch
enhancement

Tracking

()

Performance Impact low

People

(Reporter: djvj, Unassigned)

References

(Depends on 30 open bugs, Blocks 3 open bugs)

Details

(Keywords: meta, perf)

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).
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).
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.
CC Servo people
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.
Whiteboard: [qf]
Whiteboard: [qf] → [qf:p1]
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.
(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.
Blocks: 1357187
Depends on: 1351781
Depends on: 1351790
Depends on: 1351800
Blocks: 1358899
Depends on: 1357813
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.
Assignee: nobody → sstangl
Depends on: 1366364
FWIW, I'm also looking at to use idle time for CC and GC timers which nsJSEnvironment has.
Depends on: 1368972
Blocks: 1370181
Blocks: 1374797
Whiteboard: [qf:p1] → [qf:p2]
Depends on: 1384049
Depends on: 1384552
Depends on: 1399141
Keywords: perf
Whiteboard: [qf:p2] → [qf:p3]
Priority: -- → P3
Keywords: meta
Summary: Implement a GC scheduler → [meta] Improve GC scheduling
Alias: GCScheduling
No longer blocks: 1370181
Depends on: 1370181
Depends on: 1390498
Depends on: 1421966
Depends on: 1514281
Depends on: 1515414
Depends on: 1518677
Depends on: 1489633
Depends on: 1450787
Depends on: 1504623
Depends on: 1501238
Depends on: 1495734
Depends on: 1521524
Depends on: 1520471
Depends on: 1392547
Assignee: sstangl → jcoppeard
Depends on: 1531088
Depends on: 1525623
Depends on: 1448548
Depends on: 1525983
Depends on: 1531744
Depends on: 1533449
No longer depends on: 1392547, 1501238, 1504623, 1525623, 1531088, 1531744
Depends on: 1395509
Depends on: 1537649
Depends on: 1537652
Depends on: 1537654
Depends on: 1472062
Depends on: 1538053
Depends on: 1530397
Depends on: 1540986
Depends on: 1535958
Depends on: 1504043
Depends on: 1543776
Depends on: 1548182
Depends on: 1548185
Depends on: 1556467
Depends on: 1557771
Depends on: 1563755
Depends on: 1495355
Depends on: 1568677
Depends on: 1570905
Depends on: 1573125
Depends on: 1576829
Depends on: 1592598
Depends on: 1673764
No longer depends on: 1673764
Depends on: 1675153
Depends on: 1673764
Assignee: jcoppeard → nobody
No longer blocks: 1345717
Depends on: 1345717
Performance Impact: --- → P3
Whiteboard: [qf:p3]
Depends on: 1770763
Severity: normal → S3
Depends on: 1814510
You need to log in before you can comment on or make changes to this bug.