Have heuristics to better predict when it is a good moment to purge
Categories
(Core :: Memory Allocator, enhancement)
Tracking
()
People
(Reporter: jstutte, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Tests for bug 1903758 showed that most of the benefit of deferred purging comes from letting an arena re-use recently freed memory without ever giving it back to the OS.
We could introduce a concept of "last significant re-use" on each arena, that tells us how much time passed since we successfully re-used a page since the last purge request was issued, assuming that a recent re-use makes it more likely for other re-uses to come. It might be as easy as the last time that mNumDirty went down for re-use.
A similar concept could also be applied to chunk recycling.
Once we have that information, we can easily use this during moz_may_purge_one_now to determine if there is any arena (or the recycled chunk list) that needs purging (cleanup) by just iterating over the list of purge requests and comparing that timestamp with now, and (if requested) do the work only for those.
|
Reporter | |
Comment 1•9 days ago
|
||
A first sketch how this could look like.
The basic idea is:
- whenever we re-use more memory than the significance threshold we raise the bar of significance to that level of usage and update the timestamp
- whenever we free memory, we reset the bar of significance to the new, lower level of usage but do not update the timestamp
- when we may want to schedule an idle purge, we consider only purge requests that had no re-use for longer than a grace period
This should ensure that we do not count every up and down as a "significant reuse" but converge to a new average level that we want to purge for.
We do that per-arena based an mNumDirty as input for the threshold as well as for the recycled chunks list as a whole based on gRecycleSize.
Description
•