[Gc] Re[34]: GC + Windows Mobile + Threads + Patch for WINCE

Boehm, Hans hans.boehm at hp.com
Sun Oct 18 20:23:45 PDT 2009


> From:  Ivan Maidanski
> Sent: Sunday, October 18, 2009 9:11 AM
> 
> Hi!
> Zeyi Lee <biosli at hotmail.com> wrote:
> > Dear Ivan:
> > > I've changed the allocation routines (this minimizes 
> overflow of heap sections), so it's crucial to retest case 1 
> again (with 64K stack).
> > I've downloaded the version at 09/09/17 in CVS. And I test 
> the original edition, only defined VERY_SMALL_CONFIG.
> > The output as below:
> > ----------------------
> > Received WM_CLOSE, closing window
> > ...
> > Total number of bytes allocated is 21653080 Final heap size is 
> > 17555456 bytes Unexpected heap growth - collector may be broken 
> > Collector appears to work
> > ----------------------
> > Is the output with "Unexpected heap growth - collector may 
> be broken" means the collector could not work?
> 
> I believe this doesn't imply the GC is broken - the message 
> printed because the corresponding assert condition is too 
> restrictive (I had tried to relax it a little but failed, so 
> I leave it as-is).
> 
I remain a bit nervous about this one, especially since the difference between total bytes allocated and final heap size seems very small.  I'd at least check GC_dump() output to make sure that the root set looks reasonable, i.e. that we're not scanning memory areas we shouldn't, and that the heap doesn't overlap with the root set.  If this is reproducible, it sometimes helps to set a breakpoint in one of the last calls to GC_expand_hp_inner to try to understand why the heap got so big.

I guess an unusually large amount of blacklisting might also contribute.  That could again be caused by scanning memory regions we shouldn't really be scanning (code segments, graphics memory, etc.)

Hans


More information about the Gc mailing list