8334505: RISC-V: Several tests fail when MaxVectorSize does not match VM_Version::_initial_vector_length

[zifeihan]

HI, It's possible to specify a MaxVectorSize which is not equal to VM_Version::_initial_vector_length on RISC-V. For example, it could happen on Banana-Pi that MaxVectorSize equals 16, while VM_Version::_initial_vector_length is 32. This may lead to several jtreg test failures, see jbs issue for exception information.

The reason for this problem is that when spill vector registers into memory, the whole width of the register is used incorrectly, and MaxVectorSize should be used to handle the number of elements spill.

jdk/src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp

Lines 133 to 136 in 326dbb1

	void spill(VectorRegister v, int offset) {
	add(t0, sp, offset);
	vs1r_v(v, t0);
	}

PR propose to simply set MaxVectorSize to VM_Version::_initial_vector_length for the following reasons:

1. The CSR_VLENB register of RISC-V is read-only, we can't change it to MaxVectorSize like like aarch64.
2. It does not make sense to me to set MaxVectorSize to a value smaller than VM_Version::_initial_vector_length in the real world, which might bring negative impact on performance.
3. If MaxVectorSize equals to VM_Version::_initial_vector_length, then we can make use of vs1r_v/vl1r_v when saving and restoring vector registers, which avoids the need to control the number of elements with vsetvli.

After this patch, MaxVectorSize always equal to VM_Version::_initial_vector_length:

zifeihan@plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:MaxVectorSize=16 -XX:+PrintFlagsFinal -version |grep MaxVectorSize
OpenJDK 64-Bit Server VM warning: MaxVectorSize is set to 32 on this platform
     intx MaxVectorSize                            = 32                                     {C2 product} {command line}
openjdk version "24-internal" 2025-03-18
OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.zifeihan.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.zifeihan.jdk, mixed mode)
zifeihan@plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:MaxVectorSize=32 -XX:+PrintFlagsFinal -version |grep MaxVectorSize
     intx MaxVectorSize                            = 32                                     {C2 product} {command line}
openjdk version "24-internal" 2025-03-18
OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.zifeihan.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.zifeihan.jdk, mixed mode)
zifeihan@plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:MaxVectorSize=64 -XX:+PrintFlagsFinal -version |grep MaxVectorSize
OpenJDK 64-Bit Server VM warning: MaxVectorSize is set to 32 on this platform
     intx MaxVectorSize                            = 32                                     {C2 product} {command line}
openjdk version "24-internal" 2025-03-18
OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.zifeihan.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.zifeihan.jdk, mixed mode)
zifeihan@plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$

Testing

• test/jdk/jdk/incubator/vector on Banana Pi BPI-F3 board (with RVV1.0)

---

Progress

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

Issue

• JDK-8334505: RISC-V: Several tests fail when MaxVectorSize does not match VM_Version::_initial_vector_length (Bug - P4)

Reviewers

• Fei Yang (@RealFYang - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19785

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back gcao! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@zifeihan This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8334505: RISC-V: Several tests fail when MaxVectorSize does not match VM_Version::_initial_vector_length

Reviewed-by: fyang

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 81 new commits pushed to the master branch:

• f101e15: 8333583: Crypto-XDH.generateSecret regression after JDK-8329538
• b3bf31a: 8333542: Breakpoint in parallel code does not work
• 86b0cf2: 8334653: ISO 4217 Amendment 177 Update
• 861aefc: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14
• f8bf470: 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression
• 933eaba: 8334629: [BACKOUT] PhaseIdealLoop::conditional_move is too conservative
• 7429c37: 8334598: Default classlist in JDK is not deterministic after JDK-8293980
• 9c89f08: 8334421: assert(!oldbox->is_unbalanced()) failed: this should not be called for unbalanced region
• 57f8b91: 8333658: NMT: Use an allocator with 4-byte pointers to save memory in NativeCallStackStorage
• 6c67933: 8334899: Test runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java failed after JDK-8306580
• ... and 71 more: https://git.openjdk.org/jdk/compare/e227c7e37d4de0656f013f3a936b1acfa56cc2e0...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@RealFYang) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[openjdk]

@zifeihan 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.

[mlbridge]

Webrevs

• 02: Full - Incremental (75fefaf2)
• 01: Full - Incremental (16428e74)
• 00: Full (096354b6)

[RealFYang]

Yeah, most of the related RISC-V code was written under the assumption that MaxVectorSize matches vlenb CSR (the vector register length in bytes). I agree it will be safer to have this change for now. Also I don't think a MaxVectorSize value smaller than vlenb would work if we want to experiment with vector register groups (LMUL > 1) some day for C2 especially when we come to vector reduction operations.

[zifeihan]

@RealFYang : Thanks for the review.
/integrate

[openjdk]

@zifeihan
Your change (at version 75fefaf) is now ready to be sponsored by a Committer.

[RealFYang]

/sponsor

[openjdk]

Going to push as commit c66f785.
Since your change was applied there have been 81 commits pushed to the master branch:

• f101e15: 8333583: Crypto-XDH.generateSecret regression after JDK-8329538
• b3bf31a: 8333542: Breakpoint in parallel code does not work
• 86b0cf2: 8334653: ISO 4217 Amendment 177 Update
• 861aefc: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14
• f8bf470: 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression
• 933eaba: 8334629: [BACKOUT] PhaseIdealLoop::conditional_move is too conservative
• 7429c37: 8334598: Default classlist in JDK is not deterministic after JDK-8293980
• 9c89f08: 8334421: assert(!oldbox->is_unbalanced()) failed: this should not be called for unbalanced region
• 57f8b91: 8333658: NMT: Use an allocator with 4-byte pointers to save memory in NativeCallStackStorage
• 6c67933: 8334899: Test runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java failed after JDK-8306580
• ... and 71 more: https://git.openjdk.org/jdk/compare/e227c7e37d4de0656f013f3a936b1acfa56cc2e0...master

Your commit was automatically rebased without conflicts.

[openjdk]

@RealFYang @zifeihan Pushed as commit c66f785.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.