On Mon, Jul 5, 2010 at 5:57 PM, Tom de Vries <tjvr...@xs4all.nl> wrote: > 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?
Or make sure to walk all if_marked roots last (isn't the problem an ordering one only?) Richard. > Regards > Tom >
