Re: int_cst_hash_table mapping persistence and the garbage collector

[Gary Funck <gary at intrepid dot com>]

On 10/11/11 10:24:52, Richard Guenther wrote:
> GF: 1. Is it valid to assume that pointer equality is sufficient
> GF: to compare two integer constants for equality as long as they
> GF: have identical type and value?
> 
> Yes, if both constants are "live"

The upc blocking factor hash table is declared as follows:

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".

(note: in the cited test case, the ->from pointers in question
are known to be "live" and did survive garbage collection.)

Given that the declaration above tells the GC that the nodes
in the blocking factor hash table are of type 'struct tree_map',

struct GTY(()) tree_map_base {
  tree from;
};


/* Map from a tree to another tree.  */

struct GTY(()) tree_map {
  struct tree_map_base base;
  unsigned int hash;
  tree to;
};

I thought that the GC would mark the ->to nodes as
live automatically?  (note: probably the only direct
reference to the integer constant that is the focus of
this discussion is in the upc_block_factor_for_type hash table.
Therefore, if it isn't seen as "live" there, it won't be seen
as live anywhere else.)

I suppose that I could declare a linear "tree list" of mapped integer
constants and let the GC walk that, but that is more of a hack than a solution.

- Gary