question about if_marked construct

[Tom de Vries]

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