Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit

[law at redhat dot com]

In message <Pine.LNX.4.56.0311181155430.10915@dberlin.org>, Daniel Berlin write
s:
 >>   >
 >>   > I really hope our GC isn't this variant that we range from a high water
 >>   > mark of 250 to 750 meg depending on random factors.
 >>
 >>
 >> It does, gcc -v prints this on a 512MB RAM machine:
 >> --param ggc-min-expand=64 --param ggc-min-heapsize=64264
 >>
 >> and on a 1GB RAM machine it prints this:
 >> --param ggc-min-expand=98 --param ggc-min-heapsize=128800
 >>
 >>
 >> The numbers I showed were obtained on a machine with 1GB RAM, when
 >> compiling on a 512MB machine, I get numbers similar to what you show
 >> above.
 >grrrr.
 >
 >
 >>
 >> Something seems strange with these params.
 >
 >Yes.
 >
 >>
 >> Just remember the stats you show above is the memory that is still in
 >> use at the end of the compilation process, not the total memory
 >> allocated during the compilation!
 >I know, I know.
 >
 >>
 >> PRE gc-allocates a significant ammount of memory. Here are the
 >> significant numbers:
 >
 >I can't imagine where.
 >
 >splitting critical edges shouldn't cause that kind of memory increase.
 >
 >We must have 150 meg of varrays (which are ggc_allocated) and random
 >garbage associated with expressions.
It's probably not the core issue, but did everyone know that each
varray element is 8 bytes?  Yup.  Using two varrays for the 
const_equiv data in integrate.c and unroll.c would cut the per-element
overhead of a varray in half.

Jeff