8330806: test/hotspot/jtreg/compiler/c1/TestLargeMonitorOffset.java fails on ARM32

[voitylov]

TestLargeMonitorOffset was introduced by 8310844 with a fix for the AArch64 platform. The same issue needs to be fixed for ARM32. With this change, we add the large slot_offset handling to the ARM32 version of IR_Assembler::osr_entry().

Testing: jtreg hotspot, jtreg jdk tier1-3.

---

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-8330806: test/hotspot/jtreg/compiler/c1/TestLargeMonitorOffset.java fails on ARM32 (Bug - P3)

Reviewers

• Sergey Nazarkin (@snazarkin - no project role)
• Dmitry Samersoff (@dsamersoff - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18891

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back avoitylov! 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]

@voitylov 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:

8330806: test/hotspot/jtreg/compiler/c1/TestLargeMonitorOffset.java fails on ARM32

Reviewed-by: snazarki, dsamersoff

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 839 new commits pushed to the master branch:

• 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
• cae94b2: 8334397: RISC-V: verify perf of ReverseBytesS/US
• 75a2afa: 8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature
• baafa66: 8334287: Man page update for jstatd deprecation
• c30e040: 8331911: Reconsider locking for recently disarmed nmethods
• 974dca8: 8334223: Make Arena MEMFLAGs immutable
• e527e1c: 8334580: Deprecate no-arg constructor BasicSliderUI() for removal
• 3a26bbc: 8185429: [macos] After a modal dialog is closed, no window becomes active
• 4b153e5: 8306580: Propagate CDS dumping errors instead of directly exiting the VM
• ... and 829 more: https://git.openjdk.org/jdk/compare/3e185c70feef3febf75c58a5d4d394a4b772105f...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 (@dsamersoff) 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]

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

• hotspot-compiler

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

• 00: Full (9799b250)

[snazarkin]

Can't we check this once before the loop? Or does such an optimization make no sense?

[bulasevich]

Hi Sergey. Thanks for looking at this.
This is not performance critical code, and the typical number_of_locks value is 0, so IF inside the FOR loop makes sense here.

[snazarkin]

I've checked the patch (one may need to use a workaround ). The JDK crashes without the patch, and passes with the patch.

[bridgekeeper]

@voitylov This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[dsamersoff]

Looks good to me

[bulasevich]

Looks good