I can image a few ways to go from here:
- leave as is, fix this when it really bothers us (risk:
exchange a known
problem for unknown hard-to-debug and/or hard-to-reproduce
problems)
- instrument if_marked functions like the one for
value_expr_for_decl to
assert if the from field is live and the to field is not live,
and fix
the
asserts
- extend garbage colllector to handle the problematic case
(problem: more
runtime and/or memory usage for garbage collection)
Any suggestions on which way to go?
Or make sure to walk all if_marked roots last (isn't the problem an
ordering one only?)
That is already done. The problem is not what happens after that
walk, but
during that walk. The code at that point assumes that the set of
marked
non-hashtable-entry objects is already stable, while the problematic
if_marked functions have the effect that that set is enlarged
during that
walk.
Hm, indeed - I know that this happens and it is not easy to avoid.
If we want to fix that in the garbage collector, we could walk the
problematic if_marked roots iteratively (without deleting unmarked
entries),
until fixed point is reached. After that we would walk (and delete
unmarked
entries) for both problematic and normal if_marked roots. However,
I don't
have good idea how we can iterate to fixed-point efficiently.
Me neither. I suppose it would be nice to avoid the situation by
dropping if_marked from problematic hashes. Can we at least
somehow figure out which one are those? (for example by
doing inefficient iteration with ENABLE_CHECKING and ICEing if
the 2nd iteration changes anything?)