On Tue, Jul 6, 2010 at 6:12 PM, Tom de Vries <tjvr...@xs4all.nl> wrote: > 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.
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?) Richard. > Tom >
