> 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? -- Eric Botcazou
