Re: Release RTL bodies after compilation (sometimes)

[Jeffrey A Law <law at redhat dot com>]

On Wed, 2004-09-15 at 14:08, Michael Matz wrote:
>  The point is, that currently collection is slower the more things it has 
> to walk.
Reducing this was never the primary goal of ggc_free.  The primary 
goal of ggc_free was to return memory to the GC system faster so
that it could be re-used before the next collection point, thus
potentially reducing the peak memory usage.

The fact that we have fewer things to mark was a secondary effect.

And as I've said before, ggc_free is just asking for problems given
our pointer infested code.  Rather than focusing on ggc_free, I'd
much rather see us focus on:

  1. Being smarter about our allocations to begin with.

  2. Safe means of identifying objects that should not be
     reachable, but which are reachable.  ggc_free as it stands
     today does not meet that need.



>   And another point is that all these small later-to-be-collected
> items can add up to some extreme amounts. 
Certainly.  Again, that's why we introduced ggc_free to begin with.
Unfortunately, in hindsight, we should really have been looking more
at why we were allocating so many objects rather than looking for
ways to recycle them faster.



>  We could collect more often.  
> That's slow.  Or we could build some reuse machinery on top of the GC 
> memory.  Complicated, and another layer of mem management (but sometimes 
> the right thing).  Or, if we _know_ that this or that object is dead, tell 
> the memory subsystem so, and let it make something good with this 
> information.  For instance freeing the object right now or later or never.
> 
> I.e. exactly what Daniel suggested
But given the nature of GCC, knowing an object is dead can be bloody
hard, real bloody hard.

Jeff