Re[2]: [Gc] FW: GC: Time for GC final release? (patch for cleanups)

Ivan Maidanski ivmai at mail.ru
Sun Jul 11 13:50:22 PDT 2010


Fri, 9 Jul 2010 01:19:06 +0000 "Boehm, Hans" <hans.boehm at hp.com>:

> It seems to me that we really want two patches related to cancellation that aren't yet in the tree:
> 
> 1) We should deal with the fact that apparently on Solaris and probably on Linux we can't collect while a thread is exiting, since signals aren't handled properly.  This gives currently gives rise to deadlocks.  I think the only workaround is to also intercept pthread_cancel and pthread_exit and disable GC until the thread exit handler is called.  That's ugly, because we risk growing the heap unnecessarily, and possibly repeatedly.  But it seems that we don't really have an option in that the process is not in a fully functional state while a thread is exiting.

For growing the heap (possible strategy): if unmapping is enabled and the heap has grown while GC is disabled then force max unmapping (GC_unmap_threshold = 1) on next collection.
If unmapping is off then in GC_should_collect() (and similar) ignore the impact of any possible heap growth while GC is disabled.

> 
> 2) We want to make sure that GC_thread_exit_proc() is unconditionally invoked, even if the client isn't compiled with -fexceptions, but the gc is.  Maybe the best workaround there is to put GC_inner_start_routine() in its own file, and undefine __EXCEPTIONS in the gcc case at the top of that file.  I'm still nervous about whether this will actually cause the exit handler to be invoked last if -fexceptions is used when thread_exit is called.  This may require some testing.

Ok. I've prepared the patch (attached) for the second issue (I'll apply it at the end of next week if no objections).

NIIBE Yutaka -
Could you test this patch (with and w/o -fexceptions)?


> 
> I was hoping to find some time to work on this this week. But so far, it looks like I failed.
> 
> These are both a bit frustrating, because I think they're really problems in the underlying Posix layers that are likely to also affect other things.  And they don't seem to admit good solutions
> 
> Hans
> 
> > -----Original Message-----
> > From: Ivan Maidanski [mailto:ivmai at mail.ru]
> > 
> > 
> > Fri, 2 Jul 2010 00:13:47 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> > 
> > > > From: Ivan Maidanski [mailto:ivmai at mail.ru]
> > >
> > > > My original post (detected as spam):
> > >
> > > > Hello!
> > >
> > > > Hans -
> > > > There's little GC commit activity lately. May be, it's already the
> > time to produce a final release. What do you think?
> > >
> > > I agree that we should make a 7.2 release.  The most major problem I
> > remember are the pthread cancellation issues.  And those appear to
> > reach deeper than just the garbage collector.
> > 
> > Any ideas how to solve? (As I recall previous solution had a drawback -
> > http://article.gmane.org/gmane.comp.programming.garbage-
> > collection.boehmgc/3824/)
> > 
> > >  Can you think of anything else urgent that we've dropped?
> > 
> > Could you list these ones?
> > 
> > >
> > > If you want to go ahead and do that, we should be careful to tag the
> > CVS tree correctly.  I think we neglected to do that at the last alpha
> > release, though it's probably still possible to fix that.
> > 
> > No, I don't mind waiting (it would be nice solve that cancellation
> > issues in the final release).
> > 
> > >
> > > Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 10007 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20100712/815a93ae/attachment.obj


More information about the Gc mailing list