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

[Andrew Begel <abegel at cs dot berkeley dot edu>]

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@gmx.net] 
> > Sent: Tuesday, May 30, 2006 3:07 PM
> > To: Boehm, Hans
> > Cc: java@gcc.gnu.org; gc@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@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On 
> > > > Behalf Of Juerg Lehni
> > > > Sent: Sunday, May 28, 2006 12:30 PM
> > > > To: java@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@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On 
> > > > > > Behalf Of Sandro Tolaini
> > > > > > Sent: Wednesday, May 24, 2006 11:45 AM
> > > > > > To: Juerg Lehni
> > > > > > Cc: java@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@linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/