GC scheduling and sweeping tidyups
Categories
(Core :: JavaScript: GC, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
Details
Attachments
(4 files)
In preparation for tackling bug 1627039, here are some scheduling and sweeping tidyups.
Assignee | ||
Comment 1•5 years ago
|
||
This is checkd in the allocator on every allocation, but we also check this when we allocate a new arena in maybeAllocTriggerZoneGC. It's possible that this one will hit first if background sweeping reduces the heap threshold after the last arena was allocated, but this doesn't really make any difference.
Assignee | ||
Comment 2•5 years ago
|
||
A while back we added a heuristic to delay a GC if it would cause a reset (bug 1367455), but it was turned off after it caused a performance regression and hasn't been reenabled since.
Telemetry shows that that only 0.2% of GCs get reset anyway so we should probably just remove this.
Depends on D71328
Assignee | ||
Comment 3•5 years ago
|
||
I think I meant to do this when I added the separate GCRuntime::freeTask, but as it stands both this and sweepTask try and free the LIFO data. This is unnecessary.
Depends on D71329
Assignee | ||
Comment 4•5 years ago
|
||
The reason this didn't pass before is that the sweep task may be started for every group of zones, so a single instance finishing doesn't mean that we've finished sweeping all zones, and there may be more arenas to sweep in this case.
Depends on D71330
Comment 6•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4ec83f8bd505
https://hg.mozilla.org/mozilla-central/rev/0aab8dc843cd
https://hg.mozilla.org/mozilla-central/rev/b17ee0161ec7
https://hg.mozilla.org/mozilla-central/rev/004bab704062
Description
•