Re: ggc_free

[Jan Hubicka <jh at suse dot cz>]

> Jan, I'm not sure I like the half-dozen old_foo_array patches you've
> been generating, trying to work around varray vs ggc_realloc silliness.

Yes, I don't like the old_* stuff either, ggc free would help a lot
here.  In fact I was asking Steven several times about it but he was
claiming that non-lame ggc_free is no go...
> 
> Seems to me that the proper fix is (1) don't make ggc_realloc so
> stupid, and (2) allow us to use known lifetimes of specific objects.
> Both of which are solved by implementing ggc_free, which we've talked
> about before.
> 
> The following has made it through bootstrap of gcc/, including ada.
> The build is still in the middle of libjava somewhere, but it looks
> promising.
> 
> It has not been tested with gcac because mainline fails gcac with
> or without this patch.  Which is probably Bad News...

I am going to test this myself now.  It passed last time I checked this.
(about 4 hours ago)
> 
> Anyway, I wonder if this is a better way to attack all the places
> you've been patching.

I think I can use this instead of old_* use in init_emit patch and alias
analysis patch.  (the second one has been approved, the first one is
still waiting)

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.
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.

But having ggc_free especially in combination with some sanity checking
that ggc_freed memory is no longer pointed to would be very cool!

Honza