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

Juerg Lehni lehni at gmx.net
Tue May 30 15:06:48 PDT 2006


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




More information about the Gc mailing list