Request for review (XS): 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc

Christian Thalinger christian.thalinger at oracle.com
Fri Mar 18 10:29:31 PDT 2011


Thank you both for the review.  -- Christian

On Mar 18, 2011, at 6:03 PM, Tom Rodriguez wrote:
> Yes looks good.
> 
> tom
> 
> On Mar 18, 2011, at 9:44 AM, Vladimir Kozlov wrote:
> 
>> Yes, thank you Christian
>> 
>> Vladimir
>> 
>> Christian Thalinger wrote:
>>> On Mar 17, 2011, at 5:56 PM, Vladimir Kozlov wrote:
>>>> Sorry for arguing about few lines but I think without renaming the code will be better (6 new lines instead of 7):
>>>> 
>>>> + #ifdef _LP64
>>>> +           __ ldsw(arg_lsw, O2_scratch);                  // Load LSW
>>>> + #else
>>>> +           __ ldsw(arg_lsw, O3_scratch);                  // Load LSW
>>>> +           __ srlx(O3_scratch, BitsPerInt, O2_scratch));  // Move MSW value to lower 32-bits for STD
>>>> + #endif
>>>>          __ st_long(O2_scratch, arg_msw);               // Uses O2/O3 on !_LP64
>>> Alright.  I changed my code.  Okay to push?
>>> -- Christian
>>>> Vladimir
>>>> 
>>>> On 3/17/11 2:24 AM, Christian Thalinger wrote:
>>>>> On Mar 15, 2011, at 6:22 PM, Vladimir Kozlov wrote:
>>>>>> Christian,
>>>>>> 
>>>>>> We don't support little-endian SPARC, why add a code which will never be executed?
>>>>> I thought to be on the safe side if anyone ever wants to support it.  Anyway, I removed it and updated the webrev.
>>>>> 
>>>>> -- Christian
>>>>> 
>>>>>> On side note (RFE): we should officially drop v8 support (C2 does not support already, only C1). There are already several places where we use stx/ldx without check that it is v9 (yes, we still have an assert which is fine). Also std/ldd is emulated on modern SPARC and so is very slow.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> Christian Thalinger wrote:
>>>>>>> http://cr.openjdk.java.net/~twisti/7027232/
>>>>>>> 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc
>>>>>>> Reviewed-by:
>>>>>>> After 7018378 one of the tests of java/dyn/MethodHandlesTest fails on
>>>>>>> 32-bit SPARC.  st_long uses STD on 32-bit SPARC and the LSW and MSW
>>>>>>> bits are not moved to the proper registers resulting in a wrong
>>>>>>> result.
>>>>>>> The fix is to use the correct registers for 32-bit big-endian and
>>>>>>> little-endian (just in case) SPARC.
>>>>>>> src/cpu/sparc/vm/methodHandles_sparc.cpp




More information about the hotspot-compiler-dev mailing list