On Wed, Oct 12, 2011 at 10:29 AM, Eric Botcazou <ebotca...@adacore.com> wrote: >> It maps a type node into a corresponding integer node that is >> the "blocking factor" associated with the type node. Before >> the advent of this hash table the blocking factor was stored >> in a dedicated field in the tree type node. The suggestion was >> made to move this into a hash table to save space. I chose >> the "tree map" hash table because I thought it could do the job. > > So this isn't a simple hash table since this is a map. A simple hash table > doesn't store the key in the slot, only the value; a map does. > >> The keys are valid. In the example discussed in this thread, >> there is a pointer to type node that used in a parameter declaration >> of a function prototype and also in the similarly named parameter >> of the function definition. Both tree pointers are used as keys, >> and they are "live" at the point that the GC runs. > > But somehow they aren't marked by the GC. You need to find out why, since the > value will be kept only if the key is already marked by the GC. > > By the time a GC pass is run, all trees to be kept must be linked to a GC > root. > You said that the pass was run "between the point that the function prototype > tree node was created and the point at which the function declaration was > processed". To which GC root are the keys linked between these points?
I think there is an issue when two cache htabs refer to each other with respect to GC, you might search the list to find out more. Richard. > -- > Eric Botcazou >
