This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: int_cst_hash_table mapping persistence and the garbage collector


2011/10/11 Gary Funck <gary@intrepid.com>:
> static GTY ((if_marked ("tree_map_marked_p"),
> Â Â Â Â Â param_is (struct tree_map)))
> Â Â htab_t upc_block_factor_for_type;
> [...]
> Âupc_block_factor_for_type = htab_create_ggc (512, tree_map_hash,
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â tree_map_eq, 0);
>
> I had hoped that this would be sufficient to ensure that all
> integer constant references recorded in this hash table would
> be considered "live" by the GC. ÂReading the code in tree_map_marked_p(),
> however, I see the following:
>
> #define tree_map_marked_p tree_map_base_marked_p
> [...]
> /* Return true if this tree map structure is marked for garbage collection
> Â purposes. ÂWe simply return true if the from tree is marked, so that this
> Â structure goes away when the from tree goes away. Â*/
>
> int
> tree_map_base_marked_p (const void *p)
> {
> Âreturn ggc_marked_p (((const struct tree_map_base *) p)->from);
> }
>
> This takes care of recycling an entry when the '->from' reference
> goes away, but it doesn't make sure that the '->to' reference is
> considered "live". ÂI don't understand the GC well enough to
> know when/where the '->to' entry should be marked as "live".

If "->from" is marked, then GC will mark the whole hash table entry,
including the tree_map::to field.

Currently I believe that your issue is one hash table pointing to
another one.  Basically all the objects that need to be live must be
known before the hash table marking starts, either by being already
marked in that GC run, either by having mark bits set somewhere where
if_marked option will check them correctly. In your case (correct me
if I misunderstood something) you have one hash table, marking of
which will mark more objects which are required for the correct
marking of the second hash table. GC might be simply walking the
second one first.

-- 
Laurynas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]