This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Release RTL bodies after compilation (sometimes)


> > > if calling ggc_free "fixes" a memory leak, then well, the
> > > ggc_free is wrong, no other way to look at it.
> > 
> > > ggc_free's only purpose should be to return objects to the GC pool
> > > faster (ie, before the next collection point).  Any other use is
> > > simply wrong.
> > 
> > 	I completely agree.
> > 
> > 	If GCC is not freeing memory or not freeing memory soon enough,
> > then we should track down why GC think there still is a reference and fix
> > the dangling reference or improve the GC machinery to GC more often.
> 
> There is still a lot of confustion.  One can not use ggc_free in the
> case there is dangling reference to the object or you will get abort in
> next ggc_collect run with checking enabled when GGC will travel the
> pointer to the freed object.
> 
> Only it is usefull for is to reduce the frequency of ggc_collect
> invocations and improve data locality.  (and it is also usefull to
> answer question "who is till pointing to my data")

What about renaming ggc_free to ggc_dead to make it obvious that one can
not "free" live data?

Honza
> 
> Honza
> > 
> > 	ggc_free() is wrong and I strongly disagree with using it as a
> > fundamental concept in the design and implementation of GCC.
> > 
> > David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]