One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, which would take a while, and would likely require multiple patches, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey.
Example profile is in the bug. On new benchmark and M1 Mac: Benchmark Mode Cnt Score Error Units # Before AESReinit.test avgt 15 873,842 ± 6,911 ns/op # After AESReinit.test avgt 15 533,018 ± 4,048 ns/op Additional testing: - [x] Benchmarks - [x] macos-aarch64-server-release, `jdk_security` - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` - [ ] linux-aarch64-server-fastdebug, `tier1 tier2` ------------- Commit messages: - Fix - Fix Changes: https://git.openjdk.org/jdk/pull/13996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308118 Stats: 77 lines in 2 files changed: 74 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13996/head:pull/13996 PR: https://git.openjdk.org/jdk/pull/13996
