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

Anthony Scarpino anthony.scarpino at oracle.com
Wed Feb 6 23:22:10 UTC 2019

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


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

More information about the security-dev mailing list