On Fri, 27 Feb 2026 12:55:51 GMT, xinyangwu <[email protected]> wrote:
>> ### Summary >> This PR introduces a parallel intrinsic for AES/ECB operations to replace >> the current per-block processing approach, reducing native call overhead and >> improving throughput for multi-block operations. >> ### Problem >> Except supporting AVX512, The existing AES/ECB/PKCS5Padding implementation >> suffers from three major performance issues: >> 1. Excessive stub call overhead: Each 16-byte block requires a separate >> intrinsic call, resulting in high invocation frequency >> >> 2. Inefficient instruction-level parallelism: The serialized block >> processing fails to fully utilize instruction-level parallelism >> >> 3. Redundant setup/teardown: Repeated initialization of encryption state for >> each block >> ### Changes >> Added parallel AES intrinsic implementation >> ### Testing >> JMH benchmarks >> >> It can bring about a **37.43%** performance improvement. >> >> On a Intel(R) Core(TM) i9-14900HX CPU machine with origin implements: >> >> >> Benchmark Mode Cnt Score Error Units >> AesTest.test avgt 5 11518.846 ± 68.621 ns/op >> >> >> On the same machine with optimized implements: >> >> >> Benchmark Mode Cnt Score Error Units >> AesTest.test avgt 5 8381.499 ± 57.751 ns/op >> >> >> All Tier-1 tests pass on linux-x64. This modification does not involve >> changing the encryption or decryption logic. > > xinyangwu has updated the pull request incrementally with one additional > commit since the last revision: > > 8376164: Optimize AES/ECB/PKCS5Padding implementation using full-message > intrinsic stub and parallel RoundKey addition I won't have full results today, so I'll look at it again on Monday. I can already see that my reliable reproducer for the Windows issue doesn't reproduce anymore. 🎉 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29385#issuecomment-3973920236
