Update heap trigger thresholds less often during sweep
Categories
(Core :: JavaScript: GC, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
References
Details
Attachments
(1 file)
GC heap trigger thresholds are primarily based on the amount of data retained at the end of the last GC. Calculating the retained size is tricky for an incremental GC though because the mutator continues allocating while the GC progresses.
Currently we calculate trigger thresholds for each zone once at the end of foreground sweeping that zone, and then update the threshold by subtracting some amount of bytes for every arena subsequently freed during background sweeping.
(It's important that we don't wait until the end of background sweeping to calculate the trigger because by that point it might already have been surpassed and we would trigger a non-incremental collection. This happens for workloads that continuously allocated, e.g. the splay benchmark. By dynamically updating the threshold as we go we start an incremental GC before the end of the previous one, but this only has to wait for the first GC to finish rather than running the whole thing non-incrementally)
I'm working on adding a new trigger threshold for malloc bytes. The same approach doesn't work so well because we may have many malloc allocations per arena and we don't want to have to update on every one.
Instead, we can periodically recalculate the thresholds from scratch. We don't have to do this for every arena freed so it may end up less work overall.
|
Assignee | |
Updated•7 years ago
|
|
|
Assignee | |
Comment 1•7 years ago
|
||
Currently we calculate the thresholds one and then update then once per freed arena. This doesn't work for malloc memory thresholds since there could be many frees per arena. Instead recalculate the thresholds periodically during sweeping.
Depends on D39393
|
||
Comment 3•7 years ago
|
||
| bugherder | ||
Description
•