On Tue, 16 May 2023 01:44:24 GMT, David Schlosnagle <d...@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 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)]; True, let me try that! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194807087
