question about if_marked construct

[Richard Guenther]

On Tue, Jul 6, 2010 at 6:12 PM, Tom de Vries <tjvries@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
>