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

Boehm, Hans hans.boehm at hp.com
Tue Nov 3 14:17:57 PST 2009


I just spent a bit of time debugging.  Unfortunately, in spite of both of us looking at it, the last patch to alloc.c was clearly broken, and I reverted it for now.

The problem is that GC_stackbottom can easily refer to another thread.   As a result of that, we ended up with a humongous "stack size", which caused the collector to think garbage collections were very expensive, and should be avoided at essentially all cost.  That was bad.

Unfortunately, I think that leaves us with the original pre-patch heap growth on Windows, which would still be nice to track down.  But that's probably much harder for me to reproduce.

As far as improving this code is concerned, I think we should probably just calculate total stack size once as stacks are pushed, and use that in min_bytes_allocd.  But I don't think that's a high priority.  Underestimating the stack size like we currently do should result in too frequent collections, which should reduce heap size.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Monday, November 02, 2009 12:28 AM
> To: gc at napali.hpl.hp.com
> Subject: Re[45]: [Gc]: GC + Windows Mobile + Threads + Patch for WINCE
> 
> Hi!
> A week ago I wrote:
> > Hi!
> > "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > > > Hans -
> > > > 1. the patch (attached) itself seems to look good/useful, right?
> > > It looks like a marginal improvement to me.  I would have 
> guessed that it might sometimes make the problem slightly 
> worse, since it may increase the collectors idea of how much 
> stack space it's scanning, especially since gctest is deeply 
> recursive in one or two places.  If you want to check in the 
> patch, fine.  But I think that if we want to really improve 
> matters we should at least take the number of threads into 
> consideration.
> 
> I could implement the following estimate alg:
> 1. calculate average stack size on every push_all_stacks; 2. 
> maintain global nthreads (inc/dec'ed on register/unregister 
> my thread); 3. in min_bytes_allocd(): 
> stack_size=(nthreads-1)*avr_stack_size+((&dummy) - GC_stackbottom).
> 
> Points to refine (if the alg would be applied):
> 1. Should this remain or be removed?: if (stack_size < 10000) 
> stack_size = 10000; 2. Should min_bytes_allocd() still be 
> call only once per GC?
> 
> > >  We clearly have another problem, which I don't yet understand.
> > 
> > I think completely the same (I'll check it in later (after 
> fixing the major problem) - just to treat the multi-threaded 
> case running in the single-threaded mode the same as a 
> single-threaded case.
> 
> Already checked in. Results in the folk complains...
> 
> > ...
> 
> Bye.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list