Re: ggc_free

[Jan Hubicka <jh at suse dot cz>]

> On Fri, Jan 23, 2004 at 02:03:12AM +0100, Jan Hubicka wrote:
> > I think I can use this instead of old_* use in init_emit patch and alias
> > analysis patch.
> 
> Good.  Probably the only other thing that would be needed is 
> for VARRAY_FREE to DTRT.
> 
> > (the second one has been approved, the first one is still waiting)
> 
> Assuming this ggc_free is going to work, I'd prefer they both
> be updated.
> 
> 
> > I still think in favour of using alloc_pool for allocating very many of
> > very tiny objects just because it allows easy statistics, has better
> > locality and minimal overhead.
> 
> Here I completely agree.
> 
> > Similarly I preffer allocating things outside GGC memory completely
> > whenever possible most of my other patches are around.  If you think I
> > should avoid this scheme, just tell me so I don't produce too much work
> > in this.
> 
> Another that I wonder about is the insn_address change, which
> more or less re-implements VARRAY just to avoid GGC.  I'm not
> sure I like this.

Yes.  In fact the sollution this is result of my earlier discussion with
Jeff, where I was just considering to add VARRAY support to grow in the
malloc memory on choice.  My understand of Jeff's comment was that he
want the varrays to go for hot datastructures in favour of more
specifically tunned ways.  I was unsure what to do with the
INSN_ADDRESSES array then and ended up with this sollution.

The only advantage of the new thing is that it avoid clearing out the
array that is probably not big deal at all and I would not worry about
dropping this patch.

I am using similar array to hold the log links in my patch too, perhaps
I can turn it into varray too, but then I will get it walked by GGC that
I don't want to happen (I want to rely on fact htat log links never
points to dead instructions)

Honza
> 
> 
> r~