RFR: 8376164: Optimize AES/ECB/PKCS5Padding implementation using full-message intrinsic stub and parallel RoundKey addition [v5]

[Shawn Emery]

On Tue, 24 Feb 2026 04:00:49 GMT, xinyangwu <duke at openjdk.org> 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

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 1497:

> 1495: 
> 1496:   load_key(xmm_key_tmp, key, 0x00, xmm_key_shuf_mask);
> 1497:   DoFour(pxor, xmm_key_tmp);

Can the `DoFour()` and `DoOne()` sequences have only only one instance, where there would be two conditionals for each of the other two key lengths?  It seems that this would eliminate a lot of duplication that could easily fit into this design pattern, similar to how the software block cipher is implemented ;)

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 2160:

> 2158: 
> 2159:   __ BIND(L_done_256);
> 2160:   __ jmp(L_exit);

Jump to `L_exit ` needed here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29385#discussion_r2862343702
PR Review Comment: https://git.openjdk.org/jdk/pull/29385#discussion_r2862346773