RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey
Xue-Lei Andrew Fan
xuelei at openjdk.org
Mon May 15 20:53:45 UTC 2023
On Mon, 15 May 2023 19:59:13 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. 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 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?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194351546
More information about the security-dev
mailing list