Re: Better memory statistics, take 2

[Jan Hubicka <jh@suse.cz>]

> Jan Hubicka <hubicka@ucw.cz> writes:
> 
> >> 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)
> 
> That makes sense.  Note though that the current memory-pressure
> heuristics don't run the collector at all for small to medium-sized
> input.

Yes, I do two tests always - Geralds testcase and GCC modules that
should cover both cases.  I will try to post numbers more consistenly.
> 
> > 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.)
> 
> Yes.  I wasn't clear enough: I am not objecting to this patch, only
> cautioning you not to assume that sprinkling ggc_free calls through
> the compiler will speed anything up.

Yes, I will try to be curefull.  I am experimenting with explicit
allocation/deallocation of gimple nodes, so that will likely show how
well/badly ggc_free scale.
> 
> >> 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.
> 
> Agree, use of xmalloc or obstacks for data with a well-defined
> lifetime is a good move.

don't forget about allocpool, it is prettier than obstack ;)

Honza
> 
> zw