Re: Release RTL bodies after compilation (sometimes)

[Jan Hubicka <jh at suse dot cz>]

> On Wed, 2004-09-15 at 09:46, Jan Hubicka wrote:
> > > > If we are holding onto too much unnecessary data in our algorithms, then
> > > > the solution _ought_ to involve breaking the chains to the dead data so
> > > > that we can collect all that garbage.  And the way of breaking those
> > > > chains should simply be writing NULL to your pointers.
> > > Right.  Now a good way to help find those cases would be a huge
> > > step forward.  Right now I find them by noting the object which ought
> > > to be dead, the setting conditional breakpoints in the marking
> > > routines.  Needless to say that's slow and error prone and
> > > doesn't scale well.
> > 
> > What I do is to add ggc_free on the object, wait for next ggc_collect to
> > crash and then look into backtrace that shows me who forget about that
> > case.
> > I don't see much way to make this easier, except for perhaps adding
> > ggc_free/ggc_collect pair
> Well, rather than actually freeing the object, you mark it as
> something that ought to be unreachable, but don't actually free it.
> 
> The difference is subtle, but critical.

This is precisely what ggc_free does with --enable-checking=gcac
(together with zeroing out the released chunk so we are punished for
accessing released memory). 
Since nowdays the gcac bootstraps are far from being practical (over one
day on my fastest machine) I would be happy about moving this code to
default --enable-checking too.  We also might have two kinds of
construct (ggc_free and ggc_dead) both behaving same with checking
enabled and the other compiling to noop with checking disabled if it
makes something better....

Honza