Re: Better memory statistics, take 2

[Jan Hubicka <hubicka at ucw dot cz>]

> On Sep 2, 2004, at 9:23 AM, Zack Weinberg wrote:
> 
> >Jan Hubicka <hubicka@ucw.cz> writes:
> >
> >>Hi,
> >>here is updated version of patch I sent while reducing memory for GCC
> >>3.4, it is quite usefull now again...
> >>
> >>Hi, this patch improves the per-line statistics by tracking down
> >>each allocated entity to figure out whether it will be freed,
> >>garbage collected or leaked.  To rule out ggc_freed values is pretty
> >>important as these are much cheaper,
> >...
> >
> >Please do timing tests before submitting any changes.  In my
> >experience ggc_free is *not* cheaper, it is by itself such an
> >expensive operation that we don't actually gain anything over
> >letting the garbage collector do its job.

My experience is that you need to free quite a lot of memory to see gain
(ie you need to avoid at leat one GGC run).  For Gerald's testcase I
actually measured slight change in execution time with both changes (ie
one GGC run, but it is because my memory setup is definitly on the
corner between 22 and 23 GGC runs)

This patch is not adding any ggc_free, just making analysis prettier.  I
have some extra patches dependent on the framework (ie I use it to
detect leaks where we keep pointer to something local accidentally and
it was usefull enought to reduce peak memory usage of combine.c
compilation from 12MB to 2.8MB.)
> 
> What this does mean is that if we know a data structure will be 
> temporary, we shouldn't use ggc_free or ggc_anything.

Yes, where convenient, I am trying to get out of GGC completely.

Honza
> 
> 			--Matt