Re: Collecting more frequently

Re: Collecting more frequently

[Mike Stump]

> Date: Sat, 18 Mar 2000 00:06:00 +0100
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>

> You'll notice that peak memory consumption is much lower now, and
> that time spent in collection is higher.

> I propose that garbage collection happens more frequently in the
> 'parsing' stage of input file processing. Calling it as often as
> above is perhaps not reasonable, since there is not that much new
> garbage every time. So instead, I propose that the threshold is
> higher, e.g. collection should occur after each extdef only when the
> memory consumption has doubled or tripled since the last collection.

If you want an easy way to make your change more reasonable, without
do any real work, you can just collect less often: { static int i; if
(++i % 20 == 19) gc_collect(); }.  Then you just have to find a
reasonable N.  Simple, but better than blowing out memory by not
collecting.

If your adventuresome, then a scheme that finds out how close the
machine is to paging, and then collecting on demand might be the most
optimal scheme, but this is far from portable and does introduce some
non-repeatability into the compiler that some us us would hate to see
go.

Anyway, sounds like your on the right track.

Re: Collecting more frequently

[Joern Rennecke]

> If you want an easy way to make your change more reasonable, without
> do any real work, you can just collect less often: { static int i; if
> (++i % 20 == 19) gc_collect(); }.  Then you just have to find a
> reasonable N.  Simple, but better than blowing out memory by not
> collecting.

I would rather prefer an heuristic that looks at the ratio of new
memory allocated to total memory allocated.

Re: Collecting more frequently

[Mark Mitchell]

>>>>> "Joern" == Joern Rennecke <amylaar@cygnus.co.uk> writes:

    >> If you want an easy way to make your change more reasonable,
    >> without do any real work, you can just collect less often: {
    >> static int i; if (++i % 20 == 19) gc_collect(); }.  Then you
    >> just have to find a reasonable N.  Simple, but better than
    >> blowing out memory by not collecting.

    Joern> I would rather prefer an heuristic that looks at the ratio
    Joern> of new memory allocated to total memory allocated.

We already do this.  Look at  ggc_collect for details.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Collecting more frequently

[Joern Rennecke]

> We already do this.  Look at  ggc_collect for details.

Hmm, so does this heuristic take too much time?  Maybe if you change the
constant from 1.3 to 1.25 or 1.5, gcc can compile the multiply to a shift
and an add?

Re: Collecting more frequently

[Mark Mitchell]

>>>>> "Joern" == Joern Rennecke <amylaar@cygnus.co.uk> writes:

    >> We already do this.  Look at ggc_collect for details.

    Joern> Hmm, so does this heuristic take too much time?  Maybe if
    Joern> you change the constant from 1.3 to 1.25 or 1.5, gcc can
    Joern> compile the multiply to a shift and an add?

We need to profile before we make changes like that.  I'm not sure
where 1.3 came from -- Alex and Richard iterated a little bit to get
to that number by some empirical measure of goodness.  I have no idea
whether the actual test instructions are significant at all, relative
to the function call overhead.  But, it's certainly possible.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Collecting more frequently

[Jeffrey A Law]

  In message < 200003172349.PAA24733@kankakee.wrs.com >you write:
  > If your adventuresome, then a scheme that finds out how close the
  > machine is to paging, and then collecting on demand might be the most
  > optimal scheme, but this is far from portable and does introduce some
  > non-repeatability into the compiler that some us us would hate to see
  > go.
I briefly pondered the idea of trying to malloc a large hunk of memory
in the collector (say a few meg) and if that failed to force a collector
run and force the collector to free any pages it's got cached.

The idea was to help boxes with a limited amount of virtual memory which
do not have a usable mmap such as the m68k boxes I occasionally test on.

jeff

Re: Collecting more frequently

[Michael Meissner]

On Mon, Mar 20, 2000 at 11:00:44AM -0700, Jeffrey A Law wrote:
> 
>   In message < 200003172349.PAA24733@kankakee.wrs.com >you write:
>   > If your adventuresome, then a scheme that finds out how close the
>   > machine is to paging, and then collecting on demand might be the most
>   > optimal scheme, but this is far from portable and does introduce some
>   > non-repeatability into the compiler that some us us would hate to see
>   > go.
> I briefly pondered the idea of trying to malloc a large hunk of memory
> in the collector (say a few meg) and if that failed to force a collector
> run and force the collector to free any pages it's got cached.
> 
> The idea was to help boxes with a limited amount of virtual memory which
> do not have a usable mmap such as the m68k boxes I occasionally test on.

Note, on systems that allow you to malloc more memory than is available as long
as you don't touch it (ie, Linux) it will rarely be invoked.  I'm not arguing
against it per se, but wanted to raise the issue in case people weren't aware
of it (it comes up every 6 months of so in the Linux kernel mailing list).

-- 
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Collecting more frequently

[Martin v. Loewis]

> Hmm, so does this heuristic take too much time?

I would not think so. In a test case of mine (actually, of Gerald),
there were 7927 calls to "ggc_collect", of which 26 resulted in actual
collection. However, this relates to 39645517 calls to "ggc_set_mark",
6052924 calls to "fixup_var_refs_1", and 17646284 calls to "contains"
in the same test case. It is certainly possible to speed-up the
threshold test, but it would not save too much.

Regards,
Martin

Re: Collecting more frequently

[Joe Buck]

> I briefly pondered the idea of trying to malloc a large hunk of memory
> in the collector (say a few meg) and if that failed to force a collector
> run and force the collector to free any pages it's got cached.

Michael Meissner mentioned the speculative allocation problem (on Linux
and a couple of other systems), but even for conservative systems where
each allocated page must be backed by swap, virtual memory may be much
greater than physical memory, so it would would be best to have some bound
based on the estimated real memory size, so paging is avoided if possible.
Unfortunately there isn't a portable way of doing this.

Re: Collecting more frequently

[Gerald Pfeifer]

On Sat, 18 Mar 2000, Martin v. Loewis wrote:
> You'll notice that peak memory consumption is much lower now, and that
> time spent in collection is higher. On my system, this is a good
> trade-off, since a peak of 110M is close to the available main memory,
> whereas the peak of 43M in the second case is no problem.

We should be careful not to make g++ even slower than it already became
since 2.95 (due to GC, as it seems):

  http://gcc.gnu.org/ml/gcc/2000-02/msg00278.html
  http://gcc.gnu.org/ml/gcc/2000-02/msg00279.html

But I agree that memory consumption became way too high as well (three
times as much for some code of mine!), so I'm definitely interested in
such a change and would be willing test any patch you'll come up with.

Gerald

PS: Martin, Mark, the example I provided when you reduced the size of the
debugging information recently also should be useful in this case. If you
don't have that anymore, I'd be glad to send a current version to you...
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Collecting more frequently

[Martin v. Loewis]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

While compiling template-heavy C++, I found that memory consumption
dramatically goes up until the garbage collector is called the first
time. After that, it grows less intense. I figure the reason is that
g++ digests a lot of declarations, before emitting the first true
definition. Here is a trace (obtained from -Q) for stock 20000317:

{GC 5537k -> 2297k in 0.100}
{GC 5326k -> 4175k in 0.160}
{GC 87072k -> 19050k in 0.880}
{GC 24769k -> 19766k in 0.980}

Notice the peak of 87M allocated memory, which top(1) translated to
110M RSS. I've replaced in parse.y

extdefs:
		{ $<ttype>$ = NULL_TREE; }
	  lang_extdef
		{ $<ttype>$ = NULL_TREE; }
	| extdefs lang_extdef
		{ $<ttype>$ = NULL_TREE; ggc_collect(); }
	;

i.e. I now collect after each 'global' definition. With that, I got

{GC 5350k -> 2209k in 0.100}
{GC 5332k -> 4128k in 0.160}
{GC 5832k -> 5033k in 0.200} 
{GC 6555k -> 5177k in 0.200} 
{GC 6743k -> 5256k in 0.200} 
{GC 6886k -> 5321k in 0.220} 
{GC 6923k -> 5625k in 0.220} 
{GC 7318k -> 6587k in 0.260} 
{GC 8662k -> 6915k in 0.280} 
{GC 9078k -> 6981k in 0.280} 
{GC 9182k -> 7716k in 0.320} 
{GC 10048k -> 8826k in 0.360} 
{GC 11534k -> 9188k in 0.380} 
{GC 12022k -> 9459k in 0.380} 
{GC 12369k -> 10681k in 0.440} 
{GC 13928k -> 11051k in 0.480} 
{GC 14437k -> 11557k in 0.480} 
{GC 15107k -> 12249k in 0.520} 
{GC 15932k -> 13844k in 0.600} 
{GC 18038k -> 14589k in 0.640} 
{GC 18989k -> 14687k in 0.640} 
{GC 19175k -> 14779k in 0.640} 
{GC 19223k -> 15479k in 0.680} 
{GC 20246k -> 16372k in 0.700} 
{GC 21490k -> 16492k in 0.720} 
{GC 21698k -> 16932k in 0.720}
{GC 26499k -> 19050k in 0.820}
{GC 24769k -> 19766k in 0.900}

You'll notice that peak memory consumption is much lower now, and that
time spent in collection is higher. On my system, this is a good
trade-off, since a peak of 110M is close to the available main memory,
whereas the peak of 43M in the second case is no problem.

I propose that garbage collection happens more frequently in the
'parsing' stage of input file processing. Calling it as often as above
is perhaps not reasonable, since there is not that much new garbage
every time. So instead, I propose that the threshold is higher,
e.g. collection should occur after each extdef only when the memory
consumption has doubled or tripled since the last collection.

I'd be willing to work on a patch for that strategy if desired.

Regards,
Martin

P.S. In case anybody wants to experiment with my data, I attach the
source I've used below. It is from ORBacus 4.0b2.


[-- Attachment #2: GenCPPTieH.ii.bz2 --]
[-- Type: application/x-bzip2, Size: 62731 bytes --]