On Mon, 15 May 2023 19:59:13 GMT, Aleksey Shipilev <sh...@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, > 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` src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1369: > 1367: int BC = 4; > 1368: int[][] Ke = new int[ROUNDS + 1][]; // encryption round keys > 1369: int[][] Kd = new int[ROUNDS + 1][]; // decryption round keys This is more a question of curiosity and likely beyond the scope of this PR/bug ID -- would it be beneficial to refactor this to allocate and operate over just two arrays, one for Ke and one for Kd, effectively removing the need for allocation in `expandToSubKey` as well? int[] Ke = new int[4 * (ROUNDS + 1)]; int[] Kd = new int[4 * (ROUNDS + 1)]; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194511682
