RFR 8177784 Use CounterMode intrinsic for AES/GCM

Sean Mullan sean.mullan at oracle.com
Mon Apr 10 19:18:34 UTC 2017

On 4/6/17 4:39 PM, Anthony Scarpino wrote:
> I'd like to get a review for this performance change to use the existing
> CounterMode parallelized intrinsic instead of GCTR's own version. The
> two classes were nearly identical except for the doFinal() method which
> doesn't belong in CounterMode.java.
> I could have been more aggressive with this change, but I'm looking to
> get this into 9, so I stayed away from completely merging GCTR into
> CounterMode in case of incompatibilities.

If there is some additional followon work or additional performance 
improvement that you think should be done, please file that as a 
separate issue.

> All tests security and
> hotspot tests pass.
> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/


I had one question about the clone on line 62 -- it did not seem 
necessary as the array was subsequently copied in the reset method and I 
don't think the iv is needed again. Also a nit on line 66, add @Override 
to getFeedback(). Also, not part of your change but the doFinal method 
does not need to be protected - package-private is fine/better.

Otherwise, it looks good to me.


More information about the security-dev mailing list