Atomic::cmpxchg_ptr code duplication

[Xiaobin Lu]

You are right, John. The only problem on Mac is the C++ overloading issue.

Sorry for the confusion.

-Xiaobin

On 04/02/09 14:31, John Coomes wrote:
> Xiaobin Lu (Xiaobin.Lu at Sun.COM) wrote:
>   
>> On Mac OS X, I believe intptr_t is typedefed as "int" on both 32 & 64 
>> bit. So, sizeof(intptr_t) on 64 bit Mac OS is still 4 and size(void*) is 8.
>>     
>
> intptr_t has to be big enough to hold a void* (it's in the c99
> standard).
>
> I think there were c++ overloading problems on MacOS because 32-bit
> intptr_t is unsigned long, instead of unsigned int as it is on Solaris
> & Linux.  Even though they're the same size, overloading considers
> them different types.
>
> -John
>
>   
>> John Coomes wrote:
>>     
>>> Paul Hohensee (Paul.Hohensee at Sun.COM) wrote:
>>>   
>>>       
>>>> Sometimes compilers don't inline all the way through a call stack,
>>>> i.e., they may have limits on inlining depth.  It's not a matter for
>>>> the preprocessor, since we're talking methods, not macros.
>>>>
>>>> Assembly code template are things like gcc asm statements or
>>>> .il functions.  Doesn't matter which.  What matters is whether the
>>>> compiler actually inlines the asm code where you want it.
>>>>     
>>>>         
>>> That's the kind of thing I was actually wondering about, along with
>>> portability--consolidating them only works if sizeof(void*) ==
>>> sizeof(intptr_t) on every platform.  They're the same on the platforms
>>> SE supports, but maybe there are some oddball embedded platforms
>>> around.
>>>
>>> -John
>>>
>>>   
>>>       
>>>> Christian Thalinger wrote:
>>>>     
>>>>         
>>>>> On Thu, 2009-04-02 at 09:54 -0400, Paul Hohensee wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> If the platform-dependent versions are assembly code templates, then
>>>>>> it's likely at some point that the C++ compiler(s) didn't inline
>>>>>> properly
>>>>>> using your suggested code.  I haven't looked in awhile, but I'm pretty
>>>>>> sure there
>>>>>> are some places that use your style of code and others that don't for
>>>>>> because of that.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Hmm, not sure I understand.  AFAIK it makes no difference for inlining
>>>>> in what header file the inline is defined, as long as both are included
>>>>> and the compiler (preprocessor) finds it.  Or do you mean something
>>>>> different by "assembly code templates", like .il files?
>>>>>
>>>>> -- Christian
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090402/c0ac7491/attachment.html