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

[Vladimir Kozlov]

Yes, it works for push. Thank you for information.

Vladimir 

> On Jan 24, 2019, at 6:31 PM, Fairoz Matte <fairoz.matte at oracle.com> wrote:
> 
> HI Vladimir,
> 
> Yes, it is difficult to run for 10_000 iterations in this case as it takes 15 to ~16mins.
> Test case takes 8mins to run 5_000 iterations.
> Crash is observed between 2_900 to 3_400 iterations, 
> So I am running for 5_000 iteration with 10mins timeout.
> Do let me know, if this works out for push?
> 
> Thanks,
> Fairoz
> 
>> -----Original Message-----
>> From: Vladimir Kozlov
>> Sent: Thursday, January 24, 2019 11:10 PM
>> To: Fairoz Matte <fairoz.matte at oracle.com>; Tobias Hartmann
>> <tobias.hartmann at oracle.com>; hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: [13] RFR(S): 8209951 : Problematic sparc intrinsic:
>> com.sun.crypto.provider.CipherBlockChaining
>> 
>> Good.  This intrinsic is used only after method become hot and compiled by
>> C2 JIT. You need a lot of iteration to trigger C2 compilation - C2 compiling
>> threshold is 10_000. The test should iterate at least that much (not 5_000).
>> How long test run with 5_000 iterations? May be it is not practical to run
>> 10_000 if it takes 30 min :(
>> 
>> Thanks,
>> Vladimir
>> 
>>> On 1/23/19 11:14 PM, 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
>>>>>>>