On Tue, 24 Feb 2026 04:00:49 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 managed to find two Intel machines with AVX-512 support:
**Intel(R) Xeon(R) 6982P-C** and **Intel(R) Xeon(R) Platinum 8480**.
On both systems, I confirmed that `UseAVX=3` and `UseKNLSetting=true` were
enabled, and that execution indeed reached my newly added
`generate_electronicCodeBook_[en/de]cryptAESCrypt_Parallel` path.
However, I still was not able to reproduce the failure you observed. I ran the
test with the following command:
jtreg -vmoptions:"-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions
-XX:+UseKNLSetting" \
-va -jdk build/debug-aes/images/jdk \
test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java
@marc-chevalier Could you please let me know:
- Were there any additional JVM flags or test parameters used in your run?
- Did you run only `TestAESMain.java`, or was this part of a larger test suite
execution?
Any extra details would be very helpful for me to reproduce and investigate
this issue.
Thanks again for reporting this and for your help in tracking it down!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29385#issuecomment-3966401774
