question about if_marked construct

[Tom de Vries]

Hi,

>> The tree_map_base_marked_p checks ggc_marked_p on the from field.  
>> During
>> ggc_scan_cache_tab, if the from field is live, also the to field  
>> is marked
>> live.
>> I wrote some code to do sanity testing and found a similar  
>> scenario as
>> before:
>> - a register attribute is not marked live during root marking
>> - reg_attrs_htab is traversed, and the hash table entry  
>> corresponding to the
>> register attribute is removed
>> - value_expr_for_decl is traversed, a from field is found live, so  
>> the to
>> field is also marked live, marking the register attribute live.
>>
>> Is this valid use of the garbage collector?
>
> Originally the if_marked hook was supposed to be used only for
> caching purposes.  So it doesn't matter whether an element is
> collected or not for correctness.  If we now have accumulated other
> uses we indeed have to worry about this scenario (and I think it
> won't work very well there).
>
> Richard.


For my understanding: is it correct if I translate 'to be used only  
for caching purposes' to 'the compiler is free to ignore the  
if_marked function and remove all if_marked hash table entries'?
I just tried that in a bootstrap build, and that breaks already in  
stage 1.

 From looking at all the if_marked functions in gcc, a typical use  
case seems to be the one of uniqueness (also the use case described  
in the docs): making sure there is only a single object with certain  
properties, such that a test for structural equality can be replaced  
with a pointer equality comparison. This is well supported by the  
current implementation, but correctness does depend on whether a hash  
table element is collected or not.

What is not well supported, is marking live something else than hash  
table entries during ggc_scan_cache_tab. Following the scenario I  
mention above, we can end up with 2 structurally equal objects, while  
the code assumes that's not possible, and tests structural equality  
by pointer comparison. This is the scenario I worry about.

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?

Regards
   Tom