This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Better memory statistics, take 2
> 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