On Mon, 15 May 2023 20:51:21 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> 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. This workaround is straight-forward >> and backportable. >> >> 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` >> - [x] linux-aarch64-server-fastdebug, `tier1 tier2` > > src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1372: > >> 1370: >> 1371: // It is significantly faster to allocate individual arrays, >> 1372: // instead of doing the multi-array allocation. See >> JDK-8308105. > > Alternatively, could the multi-array allocation get improved? Yes, it could and it eventually would, but it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. This workaround, on the other hand, is straight-forward and backportable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194673153
