Re: gc question

[Jan Hubicka <hubicka at ucw dot cz>]

> In message <827C18A4-1C61-11D8-9E98-000A95DA505C@dberlin.org>, Daniel Berlin wr
> ites:
>  >
>  >On Nov 21, 2003, at 3:26 PM, law@redhat.com wrote:
>  >
>  >>
>  >> So lets say I wanted to like show me every GC allocation of a 
>  >> particular
>  >> type which is still active at time X?
>  >>
>  >> For example, I'd like to verify that if we GC after we leave the 
>  >> tree-ssa
>  >> path that every SSA_NAME and every PHI is collected.  Or slightly more
>  >> ambitious that every varray used by the SSA optimizers is gone.
>  >>
>  >> Any chance of doing that?  Hints?
>  >>
>  >
>  >I have a collector that is based on the zone collector that can do 
>  >this, because it marks each allocation with the typecode (by having a 
>  >ton of different ggc_alloc macros).
>  >
>  >Other than that, you probably can't do this easily.
> I don't mind doing some post-processing, or hacking into the allocator to
> do something like build a hash table of things I care about, invalidating
> them if they're released, etc etc.
> 
> Basically I want to accomplish two things.  First, nodes that I know should
> have been collected were actually collected.  Second, I'm seeing some odd
> stuff with varrays which makes me wonder if somewhere, somehow we're 
> holding on to some pointers to them and not collecting the varrays.

I was thinking that possibly we want to extend ENABLE_CHECKING API of
ggc_alloc to pass line number/file around and produce statistics per
call site.  While this itself would not be very usefull (we would
discover that most of calleers come form RTL/tree building rountines),
we may augument these as well so we will get more precise answer on who
is allocating most of RTLs or trees or such.

Combining this idea with some tracking code would answer how to check
the varrays coming from tree-dfa.c...

If this seems like good idea, I can prepare initial patch modifying
ggc_alloc once I get past the current problems with tree-ssa.

Honza
> 
> jeff