[Gc] Changes requested to reduce GC heap growth on Windows

Boehm, Hans hans_boehm at hp.com
Wed Jan 28 10:35:24 PST 2004

To my eyes, the code involving the Sleep(10) call should have no effect
other than to slow down the collector (especially since it's sleeping in
code that should hold the allocation lock).  Under nearly all conditions,
this loop should execute once per call.  The first iteration should
either garbage collect or expand the heap sufficiently to ensure that
the second call to GC_allochblk will succeed.  If the heap expansion attempt
fails repeatedly due to poor OS behavior or whatever, it should tell you about that
pretty quickly and die.  I don't see how that can result in extra heap

If the collector in use here is recent enough to support, it would be very
useful to rerun the problematic case with the GC_PRINT_STATS and
GC_DUMP_REGULARLY environment variables defined.  This should generate
annoyingly large volumes of output, but that should tell us something.
If this isn't feasible, try calling GC_dump() from a debugger after
things have started to go haywire.

If I had to make some wild guesses as to what's causing the problem here, I'd
guess one of the following:

1) Too many misidentified pointers, probably because the collector is tracing
large volumes of compressed data.  This will result in a large number of blacklisted
pages (check GC_dump() output), and may cause repeated heap expansion as described here.
It doesn't explain why the Sleep() call would help.  If that's the case, you probably need
to get the Mono implementers to tell the collector about pointerfree arrays.

2) Someone is calling GC_alloc_large() or a similar internal routine without the
allocation lock.  This is a long shot, but it's my best explanation of why Sleep(10)
might help.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Bernie Solomon
> Sent: Tuesday, January 27, 2004 11:04 AM
> To: Derek McUmber; Andrew Begel
> Cc: 'gc at linux.hpl.hp.com'
> Subject: Re: [Gc] Changes requested to reduce GC heap growth 
> on Windows
> I am sure the short circuit of && is evaluated correctly... 
> however the
> change
> includes a Sleep call and a comment about giving windows time to do
> something... surely that is the change that is making the 
> difference...
> Bernie Solomon
> ----- Original Message ----- 
> From: "Derek McUmber" <derek.mcumber at datamtnsol.com>
> To: "Andrew Begel" <abegel at eecs.berkeley.edu>
> Cc: "'gc at linux.hpl.hp.com'" <gc at napali.hpl.hp.com>
> Sent: Tuesday, January 27, 2004 10:15 AM
> Subject: Re: [Gc] Changes requested to reduce GC heap growth 
> on Windows
> Thanks for your feedback.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list