On 12/02/15 10:40:50, Richard Biener wrote: > On Tue, 1 Dec 2015, Gary Funck wrote: > > The main change recommended to reduce tree space was moving the > > "layout factor" (blocking factor) out of the tree node, and using > > only two bits there, one bit for a relatively common case of 0, > > and the other for > 1. It was suggested that we use a hash > > table to map tree nodes to layout qualifiers for the case they > > are > 1. This necessitated using a garbage collected tree map, > > which unfortunately meant that tree nodes needed special garbage > > collection logic. > > I still don't see why it needs special garbage collection logic. > We have many tree -> X maps that just get away without. > [...] > As said, I don't see why you need a special GC collection logic > at all. Please explain.
The problem we ran into is that we had a tree map which mapped a tree node to its UPC layout qualifier, which is an integral constant (CST). Tree nodes for CST's are made unique by hashing them into an integer->tree map. What happened is that the GC would free up entries in the CST table that were being used by the layout qualifier map. It seems that the new tree map logic fixes this problem (as you've noted). I backed out the custom GC logic and re-ran a large test that extensively exercises the use case that triggers the issue -- works like a charm. thanks, - Gary
