RFR(XS): 8078113: 8011102 changes may cause incorrect results

[Viswanathan, Sandhya]

Thanks a lot!  This problem existed in JDK8u as well and it would be good to consider back porting to 8u60 if possible.

Another thing I want to mention is that we would need to look into Windows OS case separately, may be another RFE.
https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx
The windows calling convention says that only XMM6-XMM15 are SOE(callee save), whereas upper 128 bits of YMM6-15 are SOC(caller save). 
This is not reflected in the x86.ad file. Also the AES stubs seem to only save the lower 128 bits for windows using movdqu.

Best Regards,
Sandhya


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Friday, April 17, 2015 4:35 PM
To: Viswanathan, Sandhya; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(XS): 8078113: 8011102 changes may cause incorrect results

Okay. I will sponsor this fix.

Thanks,
Vladimir

On 4/17/15 4:32 PM, Viswanathan, Sandhya wrote:
> Hi Vladimir,
>
> I verified the fix using the code from our customer that I got under NDA, so unable to share that.
>
> Best Regards,
> Sandhya
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Friday, April 17, 2015 3:13 PM
> To: Viswanathan, Sandhya; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8078113: 8011102 changes may cause incorrect results
>
> Looks good. How your verified the fix?
>
> Thanks,
> Vladimir
>
> On 4/17/15 3:05 PM, Viswanathan, Sandhya wrote:
>> Hi All,
>>
>> We would like to contribute a patch for bug 8078113 from Intel.
>>
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8078113
>>
>> webrev: http://cr.openjdk.java.net/~kvn/8078113/webrev.00/
>>
>> With 32 byte width vectorization the JVM produces wrong results under
>> certain circumstances for x86_64.
>>
>> The Vzeroupper instruction introduced in String.equals, String.compareTo
>> and OptimizeFill intrinsic/stubs in the following change set is the
>> cause of the bug:
>>
>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/d59ed8d47aed
>>
>> For 32 byte vectorization, YMM registers are used by the hotspot
>> compiler and the register allocator can allocate these across intrinsic
>> methods.
>>
>> Vzeroupper in the intrinsic is clobbering upper 16 bytes in all the
>> other YMM registers that are not touched in these methods and so our
>> customers are
>>
>> seeing unexpected results.
>>
>> This patch fixes the problem on Linux.
>>
>> Best Regards,
>>
>> Sandhya
>>