RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2]
Aleksey Shipilev
shade at openjdk.org
Wed May 17 12:59:49 UTC 2023
On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev <shade 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.
>>
>> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely.
>>
>> Example original profile is in the bug.
>>
>> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns.
>>
>> On new benchmark:
>>
>>
>> Benchmark Mode Cnt Score Error Units
>>
>> ## Mac M1
>>
>> # Before
>> AESReinit.test avgt 15 873,842 ± 6,911 ns/op
>>
>> # After
>> AESReinit.test avgt 15 347,632 ± 8,764 ns/op ; <--- 2.5x faster
>>
>> ## Xeon, c6.8xlarge
>>
>> # Before
>> AESReinit.test avgt 15 1524.307 ± 24.231 ns/op
>>
>> # After
>> AESReinit.test avgt 15 554.727 ± 12.876 ns/op ; <--- 2.75x faster
>>
>> ## Graviton, m6g.4xlarge
>>
>> # Before
>> AESReinit.test avgt 15 1913.492 ± 23.489 ns/op
>>
>> # After
>> AESReinit.test avgt 15 639.701 ± 5.033 ns/op ; <--- 2.99x faster
>>
>>
>> Additional testing:
>> - [x] Benchmarks
>> - [x] macos-aarch64-server-release, `jdk_security`
>> - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>
> - Micro-optimizations
> - Handle Kd
> - Handle Ke
@XueleiFan, or anyone else, please take a look?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1551343907
More information about the security-dev
mailing list