Re: [PATCH/RFC/PR28071]: New scheduler dependencies lists.

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:
> >Hi,
> >the memory tester jammed for last week, but looking at the results
> >on the PR28071 -O3 compilation at:
> >http://www.suse.de/~gcctest/memory/graphs/index.html
> >it looks like that while this patch sucesfully addressed the compilation
> >time issues, the overall memory consumption increased noticeably (100MB,
> >or 20%)
> 
> Hi,
> 
> I tested my patch on PR28071 testcase on x86_64 and got the following 
> numbers:
> 
> Revisions of interest: r121493 (the one before my patch), r121494 (the 
> one after my patch).
> 
> configure: --enable-languages=c --enable-checking=release 
> --enable-gather-detailed-mem-stats --disable-bootstrap
> 
> maxmem.sh:
> r121493: 701M
> r121494: 440M

The problem might be that garbage collector use amount of available
memory to limit collecting, so if your machine has a lot of ram, the
peak of smaller datastructure in GGC can be greater than peak of larger
datastructure in obstacks.  You might try to trottle down the GGC
parameters.

But it is also possible this actually was a bug in accounting (there was
problems with original version of maxmem script).  Also please use the
current version from Richi's website (or ggctester's)
> 
> I'm now testing the patch that among other things changes obstacks into 
> alloc_pools, but on this testcase it gives exactly the same results as 
> current obstack implementation.  So that is not the problem.

At least -fmem-report should now tell you how large the allocpools are.
The allocpool by itself does not save memory.  My original reading of
your code was that it is allocating the list elements off the obstack
and not freeing them as early as it could.  If you get the ellements
freeded you might end up with smaller peak.

Honza

> 
> 
> Thanks,
> 
> Maxim