Open Bug 1370181 Opened 7 years ago Updated 2 years ago

Don't start possibly-long-running GC work when there's not much time left in the budget

Categories

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

55 Branch
enhancement

Tracking

()

Performance Impact low

People

(Reporter: jonco, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

We have a couple of places in the GC where we defer work that must be performed atomically w.r.t. the mutator and may overrun the slice budget to a new slice. When we start to have slices triggered from idle timers we may get very short slice budgets (e.g. 2ms) so rather than waiting for the next slice (which may be very short) we should check the remaining budget against some minimum before starting work that we think may may overrun. This would mean we may do nothing for a few slices until we get one that is large enough so we may want to cap the number of skipped slices too.
Depends on: GCScheduling
Whiteboard: [qf] → [qf:p1]
Whiteboard: [qf:p1] → [qf:p2]
Keywords: perf
Whiteboard: [qf:p2] → [qf:p1][qf:i60]
Whiteboard: [qf:p1][qf:i60] → [qf:i60][qf:p1]
Whiteboard: [qf:i60][qf:p1] → [qf:f60][qf:p1]
I'm moving this to P3 since I don't think that this change would have much effect. We already yield at start of sweeping for this reason. Other changes that are in progress (incrementalising gray and weak marking) would have a greater impact here.
Priority: -- → P3
Whiteboard: [qf:f60][qf:p1] → [qf:f60][qf:p3]
Whiteboard: [qf:f60][qf:p3] → [qf:f61][qf:p3]
Whiteboard: [qf:f61][qf:p3] → [qf:p3]
Blocks: GCScheduling
No longer depends on: GCScheduling
Performance Impact: --- → P3
Whiteboard: [qf:p3]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.