Hi Richard,
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.
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.
Tom