[Gc] Merge with gcc?

Boehm, Hans hans.boehm at hp.com
Thu Aug 13 12:52:05 PDT 2009

> From:  Ivan Maidanski
> Andrew Haley <aph at redhat.com> wrote:
> > ...
> > >>>> The version of gc in gcc is old; I want to update it from the 
> > >>>> current gc tree.
> > ...
> > > Anyway, as I see you need back-ported:
> > > - include "config.h" (for libgc building only, I guess) is not 
> > > currently in CVS (pending in my diff116);
> > > - have GC_suspend/resume_thread() and 
> GC_is_thread_suspended() for pthreads (it's interesting what 
> Hans is thinking of these API entries).
> > 
> > Hmm.  We already suspend and resume threads, so I'm not 
> sure what that 
> > would do for me.
> Miscommunicating a bit - I'm talking about the things you 
> have in gcc/boehm-gc that are missing in the current GC cvs 
> (or you're suspending and resuming threads w/o using that GC 
> API calls, right?).
As far as I remember, the gc6.6 -> 7.2 API changes were fairly minor, at least with respect to what gcj cares about.  We'll probably run into a few.  GC_finalize_all was improved (thanks Ivan), and its semantics changed a bit in the process.  But this implements a broken (and deprecated, I think) API, and the old one didn't really work right anyway, so I'm not sure anyone will actually notice.

It does look like some JVMTI support was put into gcc's version of the GC for thread suspension.  I have no fundamental objection to moving that into the upstream version in some form, though I don't really think it's a good general addition to the GC API, especially since I don't think it's implemented on Windows (?), and it's a fairly dangerous API.  (Almost all naïve uses result in deadlock ...)  I think that if we do put it into the upstream version, it's an API that needs to be either not documented at all in gc.h, or come with lots of warnings that basically say "DO NOT USE".

My reading is that the current gcc GC_suspend_thread implementation is particularly broken for general use, in that it doesn't even acquire the allocation lock.  If the target thread happens to be allocating, I expect the rest of the process will be toast.  And suspend_self() seems to violate the GC's GC_ namespace rules.  At a minimum, I think we want to fix the latter.  We want to fix the former if it doesn't interfere with JVMTI use.  If it does, perhaps these should have "jvmti" in the name.


More information about the Gc mailing list