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

[Anthony Scarpino]

Agreed..  webrev updated.. I inadvertently updated in-place.

Tony

On 2/6/19 2:19 PM, Valerie Peng wrote:
> 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