Please, consider performance improvement for CipherCore.
http://cr.openjdk.java.net/~skuksenko/crypto/8209862/

Preface.
https://bugs.openjdk.java.net/browse/JDK-8207775 add required data zeroing. That causes massive performance regression:
Regressions caused by JDK-8207775
 (Legend: <algorithm> <keyLength>/<dataSize> <regression Lin64>/<regression Win64>)
AESBench.decrypt
AES/CBC/NoPadding___ 128/01024 -17.4% / -3.9%
AES/CBC/NoPadding___ 128/16384 -3.8% / -4.3%
AES/CBC/PKCS5Padding 128/16384 -8.2% / -6.0%
AES/ECB/NoPadding___ 128/01024 -7.3% / -7.6%
AES/ECB/PKCS5Padding 128/16384 0 / -8.6%

AESGSMBench.decrypt
AES/GCM/NoPadding 128/01024 -4.4% / -3.9%

AESBench.encrypt
AES/CBC/PKCS5Padding 128/16384 0 / -2.60%

DESedeBench.decrypt
DESede/CBC/NoPadding___ 168/16384 0 / -7.20%
DESede/CBC/PKCS5Padding 168/16384 0 / -3.70%

DESedeBench.encrypt
DESede/ECB/NoPadding___ 168/16384 0 / -7.30%

In general negative performance effect caused by zeroing can't avoided. But in some cases, CipherCore can be optimized.
Here is list of performance speedup by suggested patch:
Performance improvements by suggested modification
(Legend: <algorithm> <keyLength>/<dataSize> <speedup Lin64>/<speedup Win64>)
AESBench.decrypt
AES/CBC/NoPadding___ 128/_1024 68.10% / 40.20%
AES/CBC/NoPadding___ 128/16384 52.20% / 79.10%
AES/CBC/PKCS5Padding 128/16384 38.70% / 72.60%
AES/ECB/NoPadding___ 128/_1024 29.40% / 23.90%
AES/ECB/NoPadding___ 128/16384 11.60% / 33.50%
AES/ECB/PKCS5Padding 128/16384 15.30% / 38.30%

AESGSMBench.decrypt
AES/GCM/NoPadding___ 128/_1024 7.10% / 7.10%
AES/GCM/NoPadding___ 128/16384 9.20% / 2.10%
AES/GCM/PKCS5Padding 128/16384 9.00% / 0

AESBench.encrypt
AES/CBC/PKCS5Padding 128/16384 2.50% / 0
AES/ECB/NoPadding___ 128/_1024 0 / 10.50%

DESedeBench.decrypt
DESede/CBC/PKCS5Padding 168/16384 0 / 3.40%
DESede/ECB/NoPadding___ 168/16384 4.00% / 4.40%
DESede/ECB/PKCS5Padding 168/16384 0 / 5.00%

DESedeBench.encrypt
DESede/ECB/NoPadding___ 168/16384 6.50% / 0
DESede/CBC/PKCS5Padding 168/16384 3.90% / 4.10%

That not only covers almost all regression caused by additional zeroing, but gives additional performance benefits.

The idea of the modification:
- CipherCore contains 2 methods:
  doFinal(byte[], int, int)
  doFinal(byte[], int, int, byte[], int )
  The first method allocates output array internally and invokes the second doFinal.
- At the same time, the second doFinal method contains a lot of checks and additional actions to work properly with user-provider output array. All these actions may be avoided if output array was allocated internally.

What was done:
- Some parts of the code (which can't be eliminated by knowing output array details) from method doFinal(byte[], int, int, byte[], int) were extracted to other methods (checkReinit(),prepareInputBuffer(),checkOutputCapacity()).
- doFinal(byte[], int, int, byte[], int ) was manually inlined to doFinal(byte[], int, int).
- massive manual constant propagation and dead code elimination (I have to note that hotspot JIT is unable to perform all such optimizations, JIT doesn't have enough information).

The key performance factor here is not elimination of some checks. But the fact that we can avoid unnecessary data copying and corresponds zeroing.