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

[Fairoz Matte]

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
> >>>>>