GCC memory consumption increased by recent patch!
gcctest@suse.de
gcctest@suse.de
Sat Dec 4 15:54:00 GMT 2004
Hi,
Comparing memory consumption on compilation of combine.i and generate-3.4.ii I got:
comparing combine.c compilation at -O0 level:
Overall memory needed: 25325k -> 25329k
Peak memory use before GGC: 9329k
Peak memory use after GGC: 8641k
Maximum of released memory in single GGC run: 2926k
Garbage: 42603k
Leak: 6088k
Overhead: 5744k
GGC runs: 354
comparing combine.c compilation at -O1 level:
Overall memory needed: 25889k -> 25877k
Peak memory use before GGC: 9200k
Peak memory use after GGC: 8722k
Maximum of released memory in single GGC run: 2063k
Garbage: 68059k
Leak: 6485k
Overhead: 10671k
GGC runs: 547
comparing combine.c compilation at -O2 level:
Overall memory needed: 29985k -> 29977k
Peak memory use before GGC: 12705k
Peak memory use after GGC: 12579k
Maximum of released memory in single GGC run: 2575k
Garbage: 82350k
Leak: 6305k
Overhead: 14872k
GGC runs: 549
comparing combine.c compilation at -O3 level:
Overall memory needed: 20704k
Peak memory use before GGC: 12993k
Peak memory use after GGC: 12579k
Maximum of released memory in single GGC run: 3412k
Garbage: 111176k
Leak: 6817k
Overhead: 19881k
GGC runs: 615
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 118468k
Peak memory use before GGC: 79386k
Peak memory use after GGC: 46137k
Maximum of released memory in single GGC run: 43335k
Garbage: 162034k
Leak: 10610k
Overhead: 21250k
GGC runs: 295
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 132096k
Peak memory use before GGC: 85228k
Peak memory use after GGC: 70033k
Maximum of released memory in single GGC run: 41128k
Garbage: 449315k
Leak: 10956k
Overhead: 79591k
GGC runs: 429
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 154220k
Peak memory use before GGC: 101239k
Peak memory use after GGC: 85446k
Maximum of released memory in single GGC run: 42306k
Garbage: 496293k
Leak: 10876k
Overhead: 87852k
GGC runs: 362
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 154224k
Peak memory use before GGC: 101241k
Peak memory use after GGC: 85448k
Maximum of released memory in single GGC run: 42306k
Garbage: 497581k
Leak: 10923k
Overhead: 88040k
GGC runs: 370
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory allocated via mmap and sbrk increased from 112848k to 113028k, overall 0.16%
Peak amount of GGC memory allocated before garbage collecting increased from 89411k to 89585k, overall 0.19%
Peak amount of GGC memory still allocated after garbage collectin increased from 88518k to 88693k, overall 0.20%
Amount of produced GGC garbage increased from 248644k to 249021k, overall 0.15%
Amount of memory still referenced at the end of compilation increased from 57170k to 57281k, overall 0.19%
Overall memory needed: 112848k -> 113028k
Peak memory use before GGC: 89411k -> 89585k
Peak memory use after GGC: 88518k -> 88693k
Maximum of released memory in single GGC run: 19741k -> 19771k
Garbage: 248644k -> 249021k
Leak: 57170k -> 57281k
Overhead: 45229k -> 45237k
GGC runs: 362 -> 361
comparing Gerald's testcase PR8361 compilation at -O1 level:
Overall memory allocated via mmap and sbrk increased from 95408k to 95584k, overall 0.18%
Peak amount of GGC memory allocated before garbage collecting increased from 88427k to 88601k, overall 0.20%
Peak amount of GGC memory still allocated after garbage collectin increased from 87442k to 87616k, overall 0.20%
Amount of memory still referenced at the end of compilation increased from 59204k to 59306k, overall 0.17%
Overall memory needed: 95408k -> 95584k
Peak memory use before GGC: 88427k -> 88601k
Peak memory use after GGC: 87442k -> 87616k
Maximum of released memory in single GGC run: 19381k -> 19411k
Garbage: 553262k -> 553676k
Leak: 59204k -> 59306k
Overhead: 115271k -> 115278k
GGC runs: 611
comparing Gerald's testcase PR8361 compilation at -O2 level:
Overall memory allocated via mmap and sbrk increased from 95408k to 95584k, overall 0.18%
Peak amount of GGC memory allocated before garbage collecting increased from 88427k to 88602k, overall 0.20%
Peak amount of GGC memory still allocated after garbage collectin increased from 87442k to 87617k, overall 0.20%
Amount of memory still referenced at the end of compilation increased from 59786k to 59897k, overall 0.19%
Overall memory needed: 95408k -> 95584k
Peak memory use before GGC: 88427k -> 88602k
Peak memory use after GGC: 87442k -> 87617k
Maximum of released memory in single GGC run: 19380k -> 19411k
Garbage: 602290k -> 602697k
Leak: 59786k -> 59897k
Overhead: 137437k -> 137453k
GGC runs: 654 -> 656
comparing Gerald's testcase PR8361 compilation at -O3 level:
Overall memory allocated via mmap and sbrk increased from 103080k to 103248k, overall 0.16%
Peak amount of GGC memory allocated before garbage collecting increased from 95523k to 95700k, overall 0.19%
Peak amount of GGC memory still allocated after garbage collectin increased from 88741k to 88917k, overall 0.20%
Amount of memory still referenced at the end of compilation increased from 60118k to 60237k, overall 0.20%
Overall memory needed: 103080k -> 103248k
Peak memory use before GGC: 95523k -> 95700k
Peak memory use after GGC: 88741k -> 88917k
Maximum of released memory in single GGC run: 20196k -> 20229k
Garbage: 642542k -> 642932k
Leak: 60118k -> 60237k
Overhead: 148788k -> 148798k
GGC runs: 648 -> 650
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2004-12-04 01:26:06.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2004-12-04 14:50:34.000000000 +0000
@@ -1,10 +1,24 @@
+2004-12-04 Alan Modra <amodra@bigpond.net.au>
+
+ * mklibgcc.in: Build shared libgcc and shared libunwind in gcc/.
+ Don't subst shlib_dir for SHLIB_LINK, SHLIBUNWIND_LINK,
+ SHLIB_INSTALL, and SHLIBUNWIND_INSTALL.
+ * config/i386/t-nwld (SHLIB_NAME): Use shlib_base_name in place of
+ shlib_dir and shlib_so_name.
+ * config/mips/t-slibgcc-irix (SHLIB_NAME): Likewise.
+ * config/t-libunwind-elf (SHLIB_NAME): Likewise.
+ * config/t-slibgcc-darwin (SHLIB_NAME): Likewise.
+ * config/t-slibgcc-elf-ver (SHLIB_NAME): Likewise.
+ * config/t-slibgcc-sld (SHLIB_NAME): Likewise.
+ (SHLIB_LINK): Don't use shlib_dir when creating symlink.
+
2004-12-03 Roger Sayle <roger@eyesopen.com>
* doc/tm.texi (TARGET_DELEGITIMIZE_ADDRESS): Document target hook.
2004-12-03 Richard Henderson <rth@redhat.com>
- * alias.c (component_uses_parent_alias_set): Rename from
+ * alias.c (component_uses_parent_alias_set): Rename from
can_address_p. Return bool. Reverse the sense of the result.
Reinstate the check for alias set zero.
(get_alias_set): Update to match.
@@ -190,11 +204,11 @@
2004-12-01 Jeff Law <law@redhat.com>
- * tree-eh.c (save_eptr, save_filt): Now file scoped statics.
- (honor_protect_cleanup_actions): Only create save_eptr and
- save_filt if they do not already exist.
- (lower_eh_constructs): Wipe all knowledge of save_eptr and
- save_filt before returning.
+ * tree-eh.c (save_eptr, save_filt): Now file scoped statics.
+ (honor_protect_cleanup_actions): Only create save_eptr and
+ save_filt if they do not already exist.
+ (lower_eh_constructs): Wipe all knowledge of save_eptr and
+ save_filt before returning.
2004-12-02 Kazu Hirata <kazu@cs.umass.edu>
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp 2004-12-03 14:56:31.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog 2004-12-04 14:50:35.000000000 +0000
@@ -1,3 +1,13 @@
+2004-12-04 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net>
+
+ PR c++/17011, c++/17971
+ * pt.c (tsubst_copy) <FIELD_DECL case>: Check and diagnose
+ invalid field.
+ (tsubst_copy_and_build) <COMPONENT_REF case>: Check
+ error_mark_node after member substitution.
+ * semantics.c (finish_id_expression): Call
+ finish_non_static_data_member for non-dependent FIELD_DECL.
+
2004-12-03 Nathan Sidwell <nathan@codesourcery.com>
PR c++/18782
I am friendly script caring about memory consumption in GCC. Please contact
jh@suse.cz if something is going wrong.
The results can be reproduced by building compiler with
--enable-gather-detailed-mem-stats targetting x86-64 and compiling preprocessed
combine.c or testcase from PR8632 with:
-fmem-report --param=ggc-min-heapsize=1024 --param=ggc-min-expand=1 -Ox -Q
The memory consumption summary appears in the dump after detailed listing of
the places they are allocated in. Peak memory consumption is actually computed
by looking for maximal value in {GC XXXX -> YYYY} report.
Yours testing script.
More information about the Gcc-regression
mailing list