Consider allowing all GC things to be marked gray
Categories
(Core :: JavaScript: GC, task, P3)
Tracking
()
People
(Reporter: jonco, Unassigned)
References
(Blocks 1 open bug)
Details
Currently there are some GC things that are never marked gray. If they are found to be reachable only from gray roots they are marked black. This is the case for strings, symbols, big ints and prop maps.
I believe the motivation for this is so that the cycle collector will not traverse types that cannot participate in a cycle. Note that there is another concept of which GC thing kinds are represented in the cycle collector graph, which is a smaller set of kinds (base shapes, JIT code and shapes can be gray but are not represented in the graph).
From the GC's point of view it would be nice to remove this concept as it would allow the marking code to be more generic. When marking we have to know the trace kind so we know whether to mark it gray or black when marking gray. It would be good to have a single code path for this so we could bail out early if the target is already marked.
I suspect we could move the logic for which kinds the the CC traverses to the CC itself. From a quick look this seems to happen in a couple of places anyway.
Comment 1•1 year ago
|
||
That's true. I think we should check JS::IsCCTraceKind at every point a GC thing can be added to the CC graph, so it should be okay.
Reporter | ||
Comment 2•1 year ago
|
||
Some downsides to this idea are that it potentially creates more marking work, since things can be marked black after they have been marked gray.
One area this could happen is when doing gray unmarking. We could avoid this by relaxing our rule that there are no black to gray edges. Instead we could allow black to gray edges where the target is not collectible by the CC. This does lack the clarity of the existing rule though.
Another issue is that marking things gray is slower than marking them black since we need to check both mark bits when we do this.
Updated•2 months ago
|
Description
•