8391052: RISC-V: Add electronicCodeBook (ECB) AES stubs scaled to the vector length

[zny666]

There is currently no electronicCodeBook (ECB) AES stub on RISC-V, so ElectronicCodeBook falls back to a Java loop over the per-block intrinsic: implECBEncrypt/implECBDecrypt call embeddedCipher.encryptBlock/decryptBlock once per 16-byte block, and each per-block stub call reloads all round keys (11-15 x vle32 + vrev8) before doing the 10-14 rounds.

This patch adds the two missing ECB stubs only. The existing single-block, CBC and CTR stubs are not touched.

• The ECB loops scale to the vector length with LMUL=1: the bulk loop runs m1/e32 with VL = VLMAX (register form vsetvli), so one loop shape serves every VLEN - each iteration processes VLEN/128 AES blocks (1 at VLEN=128, 2 at VLEN=256, 4 at VLEN=512), with a single-block m1 tail for the remainder. No compile-time VLEN dispatch.

• Round keys are loaded once per call, right-aligned in v4..v18 (AES-128/192/256 -> v8..v18 / v6..v18 / v4..v18), with runtime key-size dispatch, so one unrolled round body serves all three key sizes.

• The Zvkned .vs instruction forms (broadcasting an m1 round key to all element groups of a VL>4 data register) are added to the assembler; the existing .vv forms would need a key splat for multi-group data.

Performance (JMH average time, single pre-initialized Cipher.doFinal per op; same-machine, same-JDK-version A/B, patched vs unpatched), on a RVV 1.0 implementation with VLEN=256 and Zvkned, measured with perf cycles. Values are speedup ratios (unpatched / patched cycles per op):

AES-128:

Benchmark	256B	1KB	4KB	16KB
ecbEncrypt	3.41x	4.26x	4.58x	4.72x
ecbDecrypt	3.50x	4.36x	4.66x	4.80x

AES-192:

Benchmark	256B	1KB	4KB	16KB
ecbEncrypt	3.49x	4.26x	4.50x	4.63x
ecbDecrypt	3.50x	4.34x	4.58x	4.69x

AES-256:

Benchmark	256B	1KB	4KB	16KB
ecbEncrypt	3.49x	4.15x	4.46x	4.55x
ecbDecrypt	3.41x	4.26x	4.52x	4.62x

Absolute cycles/op (patched vs unpatched):

Benchmark	unpatched	patched
ecbEncrypt/128/16KB	70942	15019
ecbEncrypt/256/16KB	87320	19206
ecbDecrypt/128/16KB	72126	15029
ecbDecrypt/256/16KB	88498	19178

Instructions per op drop by ~88% (e.g. ecbEncrypt/128/16KB: 87177 -> 10385): the Java per-block loop and the per-block round-key reload are gone, and the round latency chain is shared across the blocks of each batch. At small sizes the fixed per-doFinal entry cost is a larger share of the total, so the speedup grows from ~3.4x at 256B to ~4.7x at 16KB.

Testing: AES/ECB known-answer vectors (AES-128/192/256, encrypt and decrypt) plus randomized round-trips (NoPadding and PKCS5Padding, lengths 16B-8KB) pass with the intrinsic enabled, with -XX:-UseAESIntrinsics (identical results) on qemu-riscv64 at vlen=128, vlen=256 and vlen=512, and on VLEN=256 hardware. Stub generation is confirmed via -XX:+PrintStubCode (both electronicCodeBook stubs present; absent without this patch). The performance numbers above are measured on VLEN=256 hardware only; the vlen=128/512 paths are verified for correctness, not for performance.

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Error

 ⚠️ OCA signatory status must be verified

Issue

• JDK-8391052: RISC-V: Add electronicCodeBook (ECB) AES stubs scaled to the vector length (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/32472/head:pull/32472
$ git checkout pull/32472

Update a local copy of the PR:
$ git checkout pull/32472
$ git pull https://git.openjdk.org/jdk.git pull/32472/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 32472

View PR using the GUI difftool:
$ git pr show -t 32472

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/32472.diff

[bridgekeeper]

Hi @zny666, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user zny666" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@zny666 The following label will be automatically applied to this pull request:

• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[openjdk]

The total number of required reviews for this PR has been set to 2 based on the presence of this label: hotspot. This can be overridden with the /reviewers command.

[openjdk]

@zny666 Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

[openjdk]

@zny666 Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.