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
