[Gc] RE: MacOS10.4 thread stopping code (was: Deadlock in Class::forName on OSX)

Boehm, Hans hans.boehm at hp.com
Tue May 30 15:46:23 PDT 2006


This suggests to me that if it were possible to build it both ways, that would be a good thing, especially if the pthread_stop_world version runs under Rosetta, since the current code does not?  But we will continue to need the alternative code.

Based on my earlier recollection, getting pthread_stop_world.c to work, especially under Rosetta, may still be a long shot.  But based on the earlier java at gcc.gnu.org discussion, it seems to be the only possibility for getting the GC running with threads under Rosetta.

Hans

> -----Original Message-----
> From: Andrew Begel [mailto:abegel at cs.berkeley.edu] 
> Sent: Tuesday, May 30, 2006 3:20 PM
> To: Boehm, Hans
> Cc: Juerg Lehni; gc at napali.hpl.hp.com; java at gcc.gnu.org
> Subject: Re: [Gc] RE: MacOS10.4 thread stopping code (was: 
> Deadlock in Class::forName on OSX)
> 
> The reason that the non-pthread darwin code is there is to 
> support loading libgc in apps where you don't get to control 
> main() and/or override pthread_create(). For example, if 
> you're a jnilib loaded by Java, you won't get a chance to 
> capture the pthread that is calling into your library, and 
> stopping the world during a gc won't work. Also, the only way 
> to get the stack bounds of a pthread is to specify them 
> during pthread creation. The darwin-specific code walks the 
> stack of any thread to find its bounds in a (usually) 
> reliable way (as long as your app follows the ABI). AFAIK, 
> the code was barely ported to Intel Macs, and I'm sure not 
> ported to Rosetta. If Apple is playing any games with the ABI 
> on Rosetta-enabled threads, then all bets are off that any of 
> the code will work.
> 
> Andrew
> 
> Boehm, Hans wrote:
> > Remember that the GC code is shared with non-gcj clients.  
> But if (big if) it works with the standard pthread_stop_world 
> code on 10.4, I think it would be easy to allow it to be 
> built both ways for now, and we could eventually phase out 
> the old code.
> > 
> > Hans
> > 
> >> -----Original Message-----
> >> From: Juerg Lehni [mailto:lehni at gmx.net]
> >> Sent: Tuesday, May 30, 2006 3:07 PM
> >> To: Boehm, Hans
> >> Cc: java at gcc.gnu.org; gc at linux.hpl.hp.com
> >> Subject: Re: MacOS10.4 thread stopping code (was: Deadlock in 
> >> Class::forName on OSX)
> >>
> >> Great! Thanks, Hans.
> >>
> >> Regarding your concerns about breaking older versions: As far as I 
> >> can remember, GCJ on Mac only works well since 10.4, as some Apple 
> >> weirdness in the compiler / linker slowed startup time 
> down a lot in 
> >> older versions, and broke some of the fundamental features in GCJ 
> >> (Andreas Tobler can tell more about this). Basically it 
> made GCJ on 
> >> these versions of OS X only usefull for playing around a bit and 
> >> testing some things, but not more.
> >>
> >> So if 10.4 would allow to use more standard pthread mechanisms and 
> >> using these would mean to break compatibility with 10.3 
> and lower, I 
> >> wonder how bad this really would be.
> >>
> >> Jürg
> >>
> >> Am 30.05.2006 um 23:51 schrieb Boehm, Hans:
> >>
> >>> Unfortunately, I think it's unlikely that this would work without 
> >>> debugging.  It would definitely require some hacking on 
> preprocesor 
> >>> defines.
> >>>
> >>> Currently the collector uses completely different code to
> >> stop other
> >>> threads under Darwin than it does under most other pthreads
> >> platforms,
> >>> e.g. under Linux.  (Under gc7.0, the only other pthreads
> >> platform that
> >>> uses special thread stopping code is Cygwin.)  The 
> experiment would 
> >>> involve setting things up so that the Linux code is used 
> under 10.4 
> >>> and later, and then seeing what breaks.  MacOSX experts may
> >> have more
> >>> of an idea as to whether that's even worth trying.
> >>>
> >>> I copied this message to the GC list, where it may get more of a 
> >>> response.
> >>>
> >>> Hans
> >>>
> >>>> -----Original Message-----
> >>>> From: java-owner at gcc.gnu.org [mailto:java-owner at gcc.gnu.org] On 
> >>>> Behalf Of Juerg Lehni
> >>>> Sent: Sunday, May 28, 2006 12:30 PM
> >>>> To: java at gcc.gnu.org
> >>>> Subject: Re: Deadlock in Class::forName on OSX
> >>>>
> >>>> Does this mean code from Linux could be ported to 10.4, or
> >> would it
> >>>> need to be developed from scratch?
> >>>>
> >>>> If it's a case of compiling with some source files
> >> replaced and maybe
> >>>> some minor modifications, I'm happy to try it out.
> >>>> Everything else is probably beyond my skills and knowledge.
> >>>>
> >>>> Jürg
> >>>>
> >>>> Am 24.05.2006 um 22:15 schrieb Boehm, Hans:
> >>>>
> >>>>> It sounds to me like the only hope here might be to get 
> the more 
> >>>>> standard pthread-call and signal based thread suspension
> >>>> code working
> >>>>> on MacOS X.  I think that was impossible for older
> >> versions.  A Mac
> >>>>> expert might know whether it's possible for 10.4.  Of
> >> course, that
> >>>>> might well run into other issues, since it exercises a lot more 
> >>>>> pthread corner cases than I would like.
> >>>>>
> >>>>> I'm not volunteering.  But I wouldn't be unhappy if the
> >> nonstandard
> >>>>> thread suspension code disappeared in the long run.  (In
> >> the short
> >>>>> run, older MacOS X versions will still be around, I 
> expect, so it
> >>>>> can't.)
> >>>>>
> >>>>> Hans
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: java-owner at gcc.gnu.org 
> [mailto:java-owner at gcc.gnu.org] On 
> >>>>>> Behalf Of Sandro Tolaini
> >>>>>> Sent: Wednesday, May 24, 2006 11:45 AM
> >>>>>> To: Juerg Lehni
> >>>>>> Cc: java at gcc.gnu.org
> >>>>>> Subject: Re: Deadlock in Class::forName on OSX
> >>>>>>
> >>>>>>
> >>>>>> On 24/mag/2006, at 10:14, Juerg Lehni wrote:
> >>>>>>
> >>>>>>> Would it theoretically be possible to make it compatible
> >>>>>> with Rosetta
> >>>>>>> by changing that part of the code?
> >>>>>> No, as far as I know, because this call is needed to get
> >>>> informations
> >>>>>> about thread stack status. Rosetta is probably 
> fiddling with the 
> >>>>>> internal thread status frame, hence it will not allow you
> >>>> to get it.
> >>>>>> And GC will not work without this informations.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>    Sandro
> >>>>>>
> >>>>>>
> >>>>
> >>
> > 
> > _______________________________________________
> > 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