> 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, it > would take significantly more work: there are multiple issues of differing > complexity, impact, and risk. > > Meanwhile, we can work this issue around by avoiding the multiarray > allocations in AESCrypt.makeSessionKey. We can go even deeper: replace the > multi-array with the flat array and drop `expandToSubKey` completely. > > > 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 347,632 ± 8,764 ns/op > > > Additional testing: > - [x] Benchmarks > - [ ] macos-aarch64-server-release, `jdk_security` > - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` > - [ ] linux-aarch64-server-fastdebug, `tier1 tier2`
Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: - Micro-optimizations - Handle Kd - Handle Ke ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13996/files - new: https://git.openjdk.org/jdk/pull/13996/files/7842e0e2..bb712183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13996&range=00-01 Stats: 72 lines in 1 file changed: 9 ins; 43 del; 20 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
