[13] RFR(S): 8209951 : Problematic sparc intrinsic: com.sun.crypto.provider.CipherBlockChaining

[Tobias Hartmann]

Hi Fairoz,

still looks good to me but please fix the indentation in the test (lines 56-60, 122).
No new webrev required.

Thanks,
Tobias

On 24.01.19 08:14, Fairoz Matte wrote:
> Hi,
> 
> This crash is very random and to exercise AES stability adding a unit testcase.
> Thanks Sean Coffey for bringing this into my notice.
> 
> I have updated webrev and kindly review
> http://cr.openjdk.java.net/~fmatte/8209951/webrev.01/
> 
> Note: Crash is only observed on JDK 8 with Sparc Solaris 10 machine after 3_000+ iterations.
> In the test case there is loop for 5_000 iterations and running in -Xbatch making it more
> predictable.
> 
> Thanks,
> Fairoz
> 
>> -----Original Message-----
>> From: Fairoz Matte
>> Sent: Wednesday, January 23, 2019 8:50 AM
>> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-compiler-
>> dev at openjdk.java.net
>> Subject: RE: [13] RFR(S): 8209951 : Problematic sparc intrinsic:
>> com.sun.crypto.provider.CipherBlockChaining
>>
>> Thanks Tobias and Vladimir for review.
>>
>> Thanks,
>> Fairoz
>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov
>>> Sent: Tuesday, January 22, 2019 10:27 PM
>>> To: Fairoz Matte <fairoz.matte at oracle.com>; hotspot-compiler-
>>> dev at openjdk.java.net
>>> Subject: Re: [13] RFR(S): 8209951 : Problematic sparc intrinsic:
>>> com.sun.crypto.provider.CipherBlockChaining
>>>
>>> Yes, it is good.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 1/22/19 12:22 AM, Tobias Hartmann wrote:
>>>> Hi Fairoz,
>>>>
>>>> this looks good to me.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> On 22.01.19 04:35, Fairoz Matte wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following patch,
>>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8209951
>>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8209951/webrev.00/
>>>>>
>>>>> During the call to assembled stub code
>>>>> generate_cipherBlockChaining_decryptAESCrypt_Parallel()
>>>>> there was reference to G6 register used for temporary storage of
>>>>> F50, as G6 is not saved on stack it was resulting in garbage during
>> retrieval.
>>>>>
>>>>> Solution is to use unused local register (L6) for temporary storage
>>>>> and
>>> retrieval of F50.
>>>>>
>>>>> Thanks,
>>>>> Fairoz
>>>>>