RFR[s]: 8201633 Problems with AES-GCM native acceleration

[Valerie Peng]

Hi Tony,

Changes look fine, just some nits.

- line 402, 96 bit should be 96-byte?

- line 408, can we not use "l"?  It looks too similar to "1"

- As for the comments on line 586, 587, It seems to be for the "else" 
part of this if-condition. So I find it a bit confusing. Maybe simplify 
it to something like "copy input data into ibuffer when there are 
buffered bytes or when input buffer is same as output buffer". Or, use 
what you have and add ", otherwise, copy input data into ibuffer".

You'll probably need to add noreg-perf label.

Thanks,

Valerie

On 2/5/2019 3:52 PM, Anthony Scarpino wrote:
>
> I need a review of this change which is to help the AES/GCM intrinsic 
> activate on large data sizes.  It's not the ideal resolution, which 
> splits up the crypto operation in chucks, but I significantly improves 
> performance for larger data sizes. Additionally there is an 
> optimization to not allocated and use an unnecessary buffer in the 
> init()-doFinal() case  that helped performance with large data sizes. 
> The final result was a 1MB file is encrypted at 2GB/sec vs 250MB/sec.
>
> This change is not meant to fix all possible performance bottlenecks.
>
> http://cr.openjdk.java.net/~ascarpino/8201633/webrev/
>
> Tony