This is the mail archive of the gcc-regression@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Some aspect of GCC memory consumption increased by recent patch


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: 24653k
    Peak memory use before GGC: 9351k
    Peak memory use after GGC: 8665k
    Maximum of released memory in single GGC run: 2864k
    Garbage: 41665k
    Leak: 6387k
    Overhead: 5772k
    GGC runs: 328

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25501k -> 25493k
    Peak memory use before GGC: 9224k
    Peak memory use after GGC: 8733k
    Maximum of released memory in single GGC run: 2027k
    Garbage: 61170k
    Leak: 6749k
    Overhead: 9978k
    GGC runs: 503

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29553k
    Peak memory use before GGC: 12663k
    Peak memory use after GGC: 12537k
    Maximum of released memory in single GGC run: 2597k
    Garbage: 79387k
    Leak: 6585k
    Overhead: 14118k
    GGC runs: 516

comparing combine.c compilation at -O3 level:
    Overall memory needed: 20228k
    Peak memory use before GGC: 12795k
    Peak memory use after GGC: 12537k
    Maximum of released memory in single GGC run: 3406k
    Garbage: 107335k
    Leak: 7110k
    Overhead: 18947k
    GGC runs: 582

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 114136k
    Peak memory use before GGC: 74739k
    Peak memory use after GGC: 45485k
    Maximum of released memory in single GGC run: 39340k
    Garbage: 152660k
    Leak: 10976k
    Overhead: 19969k
    GGC runs: 273

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 124276k -> 123952k
    Peak memory use before GGC: 78748k
    Peak memory use after GGC: 70095k
    Maximum of released memory in single GGC run: 40779k
    Garbage: 366122k
    Leak: 11353k
    Overhead: 69302k
    GGC runs: 396

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 147408k
    Peak memory use before GGC: 98349k
    Peak memory use after GGC: 83466k
    Maximum of released memory in single GGC run: 39384k
    Garbage: 480607k
    Leak: 11234k
    Overhead: 84551k
    GGC runs: 341

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 137904k
    Peak memory use before GGC: 98351k
    Peak memory use after GGC: 83467k
    Maximum of released memory in single GGC run: 39385k
    Garbage: 481652k
    Leak: 11273k
    Overhead: 84702k
    GGC runs: 347

comparing Gerald's testcase PR8361 compilation at -O0 level:
  Peak amount of GGC memory allocated before garbage collecting increased from 86885k to 87148k, overall 0.30%
  Amount of produced GGC garbage increased from 245826k to 246087k, overall 0.11%
    Overall memory needed: 111096k -> 111048k
    Peak memory use before GGC: 86885k -> 87148k
    Peak memory use after GGC: 85935k -> 85887k
    Maximum of released memory in single GGC run: 19282k -> 19511k
    Garbage: 245826k -> 246087k
    Leak: 55495k -> 55514k
    Overhead: 43290k -> 43323k
    GGC runs: 367 -> 366

comparing Gerald's testcase PR8361 compilation at -O1 level:
  Overall memory allocated via mmap and sbrk increased from 103713k to 103893k, overall 0.17%
  Peak amount of GGC memory still allocated after garbage collectin increased from 84933k to 85105k, overall 0.20%
    Overall memory needed: 103713k -> 103893k
    Peak memory use before GGC: 85967k -> 86006k
    Peak memory use after GGC: 84933k -> 85105k
    Maximum of released memory in single GGC run: 18946k -> 18951k
    Garbage: 445006k -> 445014k
    Leak: 56775k -> 56768k
    Overhead: 65510k -> 65385k
    GGC runs: 526 -> 523

comparing Gerald's testcase PR8361 compilation at -O2 level:
  Ovarall memory allocated via mmap and sbrk decreased from 104729k to 93848k, overall -11.59%
  Peak amount of GGC memory still allocated after garbage collectin increased from 84933k to 85106k, overall 0.20%
    Overall memory needed: 104729k -> 93848k
    Peak memory use before GGC: 85967k -> 86006k
    Peak memory use after GGC: 84933k -> 85106k
    Maximum of released memory in single GGC run: 18945k -> 18950k
    Garbage: 488017k -> 487963k
    Leak: 57372k -> 57371k
    Overhead: 75261k -> 75138k
    GGC runs: 584 -> 586

comparing Gerald's testcase PR8361 compilation at -O3 level:
  Ovarall memory allocated via mmap and sbrk decreased from 112441k to 105989k, overall -6.09%
  Peak amount of GGC memory allocated before garbage collecting run decreased from 92707k to 87142k, overall -6.39%
    Overall memory needed: 112441k -> 105989k
    Peak memory use before GGC: 92707k -> 87142k
    Peak memory use after GGC: 86227k -> 86185k
    Maximum of released memory in single GGC run: 19713k -> 19399k
    Garbage: 503725k -> 498087k
    Leak: 57523k -> 57569k
    Overhead: 76950k -> 76119k
    GGC runs: 570 -> 563

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2005-02-08 14:48:35.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2005-02-09 04:18:21.000000000 +0000
@@ -1,3 +1,51 @@
+2005-02-08  Mark Mitchell  <mark@codesourcery.com>
+
+	PR c++/19733
+	* class.c (add_method): Don't set TYPE_HAS_DESTRUCTOR.
+	(check_bases): Give warnings about a base class with a
+	non-virtual destructor, even if it is implicit.
+	(finish_struct_bits): Don't copy TYPE_HAS_DESTRUCTOR.
+	(maybe_warn_about_overly_private_class): Don't use
+	TYPE_HAS_DESTRUCTOR.
+	(finish_struct_methods): Don't set TYPE_HAS_DESTRUCTOR.
+	(check_for_override): Give it external linkage.
+	(add_implicitly_declared_members): Generate destructors lazily.
+	(check_field_decls): Use TYPE_HAS_NONTRIVIAL_DESTRUCTOR, not
+	TYPE_HAS_DESTRUCTOR.
+	(check_bases_and_members): Call check_methods before
+	check_field_decls.
+	(check_bases_and_members): Use TYPE_HAS_NONTRIVIAL_DESTRUCTOR, not
+	TYPE_HAS_DESTRUCTOR.
+	(finish_struct_1): Do not use TYPE_HAS_DESTRUCTOR.
+	* cp-tree.def (PSEUDO_DTOR_EXPR): Document.
+	* cp-tree.h (TYPE_HAS_DESTRUCTOR): Remove.
+	(lang_type_class): Add lazy_destructor.
+	(CLASSTYPE_LAZY_DESTRUCTOR): New macro.
+	(CLASSTYPE_DESTRUCTORS): Robustify.
+	(TYPE_HAS_DESTRUCTOR): Remove.
+	(check_for_override): Declare.
+	(build_vbase_delete): Remove.
+	* cvt.c (convert_to_void): Issue errors about pseudo-destructor
+	expressions.
+	* decl.c (cxx_maybe_build_cleanup): Remove dead code.
+	* except.c (dtor_nothrow): Lazily create destructors if necessary.
+	(build_throw): Use TYPE_HAS_NONTRIVIAL_DESTRUCTOR.
+	* init.c (build_delete): Lazily create destructors, if necessary.
+	(build_vbase_delete): Remove.
+	* method.c (locate_dtor): Simplify.
+	(implicitly_declare_fn): Add support for destructors.
+	* parser.c (cp_parser_lookup_name): Lazily create destructors, if
+	necessary.
+	* pt.c (check_explicit_specialization): Don't use
+	TYPE_HAS_DESTRUCTOR.
+	(instantiate_class_template): Likewise.
+	* ptree.c (cxx_print_type): Don't print TYPE_HAS_DESTRUCTOR.
+	* rtti.c (emit_support_tinfos): Robustify.
+	* search.c (lookup_fnfields_1): Lazily create destructors.
+	* typeck.c (build_class_member_access_expr): Remove
+	PSEUDO_DTOR_EXPR handling.
+	(lookup_destructor): Likewise.
+
 2005-02-08  Kazu Hirata  <kazu@cs.umass.edu>
 
 	* cxx-pretty-print.c, cxx-pretty-print.h, decl.h: Update

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]