RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey

[Aleksey Shipilev]

On Tue, 16 May 2023 01:44:24 GMT, David Schlosnagle <duke at 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