RFR 8177784 Use CounterMode intrinsic for AES/GCM

[Anthony Scarpino]

On 04/10/2017 12:18 PM, Sean Mullan wrote:
> 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/
>
> GCTR.java:
>
> 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.

I did that to minimize risk, but you're probably right.  The caller 
methods are never going to change the iv, and reset copies it, so there 
is no risk.

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

Sure

http://cr.openjdk.java.net/~ascarpino/8177784/webrev.02/

>
> Otherwise, it looks good to me.
>
> --Sean