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

Ivan Maidanski ivmai at mail.ru
Fri Nov 6 09:16:43 PST 2009


Hi!
Yesterday I wrote:
-----Original Message-----

> Hi!
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > 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.
> 
> Yes, it was bad. Thanks.
> 
> > 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.
> 
> Yes, the problem is observed less frequent (a bit).

Not really less frequent. E.g, this MinGW config (I observe FAIL occurs at least in 1/3 runs):

gcc -DALL_INTERIOR_POINTERS -DGC_THREADS -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -DDONT_USE_SIGNALANDWAIT -DGC_ASSERTIONS -I include -I libatomic_ops\src -s tests\test.c *.c -luser32

(-DDONT_USE_SIGNALANDWAIT -DGC_ASSERTIONS could be omitted; -DTHREAD_LOCAL_ALLOC could be omitted too but FAILs are less frequent.)

> > 
> > 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.
> 
> Checked in this algorithm. (I think it's better to have stack size under/over-estimated than just a hard-coded value.)

Bye.


More information about the Gc mailing list