Re: Better memory statistics, take 2

[Zack Weinberg <zack at codesourcery dot com>]

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.

> 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.

>> 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.

zw