Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag
Tom Rodriguez
Thomas.Rodriguez at Sun.COM
Fri Feb 19 10:03:22 PST 2010
s/Do floats are conerted/Are floats converted/
Looks good.
tom
On Feb 19, 2010, at 9:40 AM, Vladimir Kozlov wrote:
> I updated webrev:
>
> http://cr.openjdk.java.net/~kvn/6910664/webrev.03
>
> Thanks,
> Vladimir
>
> Tom Rodriguez wrote:
>> I was wrong about C1, it already handles this correctly. It uses float_in_dbl for fpu registers and normal for xmm.
>> tom
>> On Feb 19, 2010, at 8:46 AM, Vladimir Kozlov wrote:
>>> Thank you, Tom
>>>
>>> Yes, you are right, I did not thought that I can use Location::normal.
>>> Then the comment in the .ad files is wrong.
>>>
>>> I can fix C1 also if you point me the place.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> Tom Rodriguez wrote:
>>>> I'm not sure that's the right fix. The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right. I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad. In that case it will use Location::normal instead which will do:
>>>> // Just copy all other bits straight through
>>>> union { intptr_t p; jint ji;} value;
>>>> value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF);
>>>> value.ji = *(jint*)value_addr;
>>>> return new StackValue(value.p);
>>>> which is equivalent to your new create_float_stack_value logic.
>>>> How did we go for so long with this being broken? It's totally wrong on 64 bit. C1 has the same problem too.
>>>> tom
>>>> On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote:
>>>>> http://cr.openjdk.java.net/~kvn/6910664/webrev.02
>>>>>
>>>>> Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag
>>>>>
>>>>> Problem:
>>>>> The test has several java float locals and use XMM registers in debug info.
>>>>> But the code which restore these values during deoptimization was not
>>>>> updated for XMM registers usage. It assumes that float values were converted
>>>>> to double on stack as it was before SSE hardware when FPU was used.
>>>>>
>>>>> Solution:
>>>>> Add platform specific method to get float stack value from compiled frame.
>>>>>
>>>>> Reviewed by:
>>>>>
>>>>> Fix verified (y/n): y, test with -XX:UseSSE=0|1|2
>>>>>
>>>>> Other testing:
>>>>> JPRT
>>>>>
More information about the hotspot-compiler-dev
mailing list