Re: [Gc]: GC + Windows Mobile + Threads + Patch for WINCE
ivmai at mail.ru
Fri Nov 6 09:16:43 PST 2009
Yesterday I wrote:
> "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.)
More information about the Gc