This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
> Steven Bosscher wrote:
> >On Friday 16 February 2007 09:50, Jan Hubicka wrote:
> >>Hi,
> >>this is report from memory tester, overall it seems to be slight memory
> >>consumption increase. Are there any plans to get the memory back?
> >
> >Sandra said in a mail last week that there is supposed to be a ~2%
> >memory saving (http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00945.html).
> >That is a number that should be visible in your measurements. Are you
> >and Sandra measuring the same thing?
>
> I expect that the current mainline version does show a memory use
> regression. As I mentioned in another e-mail, I have two additional patches
> from the LTO branch that I need to bring over to clobber some critical
> cases where temporary lists are being constructed. I will try to get to
> that today. Anyway, my measurements on the LTO branch were made with those
> two additional patches in place.
Hi,
if the two additional patches will change memory usage, I will get mail
from memory tester. However there are case where amount of memory after
garbage collecting increase, this is definitly not attributable to
temporary datastructures. I am particularly puzzled by the memory
referenced at the end of compilation, in the case of PR28071 it is 6%:
comparing PR rtl-optimization/28071 testcase compilation at -O1 level:
Overall memory allocated via mmap and sbrk increased from 240608k to 246404k, overall 2.41%
Peak amount of GGC memory allocated before garbage collecting increased from 84342k to 85924k, overall 1.88%
Peak amount of GGC memory still allocated after garbage collecting increased from 73896k to 74852k, overall 1.29%
Amount of memory still referenced at the end of compilation increased from 19610k to 20861k, overall 6.38%
Perhaps little analysis would help. Memory tester now publish stuff on
webpage http://www.suse.de/~gcctest/memory/ and
http://www.suse.de/~gcctest/memory/results (I just noticed I forgot to
link from the main tester page) contains logs.
The logs in question are
http://www.suse.de/~gcctest/memory/results/200702160035/pr28071-O1.rep
(from today)
http://www.suse.de/~gcctest/memory/results/200702141642/pr28071-O1.rep
(from day before patch was comitted)
At first glance one curious fact is that:
stringpool.c:77 (alloc_node) 0: 0.0% 0: 0.0% 6875024:34.2% 528848: 1.7% 66106
ggc-common.c:193 (ggc_calloc) 6470864: 2.8% 5000784: 8.6% 1761064: 8.8% 1068056: 3.4% 516
changed to:
stringpool.c:77 (alloc_node) 0: 0.0% 0: 0.0% 7893912:37.0% 607224: 1.9% 75903
ggc-common.c:193 (ggc_calloc) 6733160: 2.9% 5000784: 8.6% 2023176: 9.5% 1068176: 3.4% 517
The ggc_calloc can be probably attributed to the vectors holding call
expressions, but how can it came into increasing memory usage of
stringpool from 6.8MB to 7.8MB?
Honza