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

["Boehm, Hans" <hans dot boehm at hp dot com>]

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
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> 
>