Consider using a counter to schedule zones for GC instead of a bool
Categories
(Core :: JavaScript: GC, enhancement, P3)
Tracking
()
People
(Reporter: sfink, Unassigned)
References
(Blocks 1 open bug)
Details
Currently, zone scheduling is all-or-nothing. At least in theory, this might result in a zone being "forgotten" and never scheduled for collection again. One way to address this is to give every zone a counter. During a GC, decrement the counter and collect that zone if it hits zero.
Then instead of scheduling a zone for GC, you set its counter to 1. Initialize the counter to 10 or 100 or 1000, so that even if there is no strong reason to schedule a zone, it'll still get collected eventually.
Alternatively and equivalently, each zone could have a "next GC" value that is compared to the major GC number. Scheduling would be setting nextGC to currentGC+1. Initially and when collecting a zone, nextGC would be set to currentGC+100.
One flaw in either implementation is that you could still end up with a situation where dependent zones are out of "phase": there are cross-zone links between zones A and B that form a cycle. Zone A has a counter of 99, zone B has a counter of 100. You'll collect them in different GCs and not find the cyclic garbage. This could be addressed in the nextGC variant by rounding to the nearest 10 (there's an equivalent for the counter version.)
Potential future additions:
-
expose an API to set the counter to an intermediate value if you think a zone might be collectable, but not strongly enough to insist that it be collected immediately.
-
use this as an additional JS_MaybeGC mechanism: if it's a good time to GC and we have zones scheduled to GC "soon", then GC. Otherwise, don't bother.
Updated•5 years ago
|
Updated•1 year ago
|
Description
•