8287396 LIR_Opr::vreg_number() and data() can return negative number

[dean-long]

This PR does two things:

• reverts the incorrect change to non_data_bits that included pointer_bits
• treats the data() as an unsigned int to prevent a high bit being treated as a negative number

---

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-8287396: LIR_Opr::vreg_number() and data() can return negative number

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)
• Christian Hagedorn (@chhagedorn - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/8912/head:pull/8912
$ git checkout pull/8912

Update a local copy of the PR:
$ git checkout pull/8912
$ git pull https://git.openjdk.java.net/jdk pull/8912/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 8912

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/8912.diff

[bridgekeeper]

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

@dean-long 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

• 01: Full - Incremental (5e19c9f7)
• 00: Full (3bc73a2e)

[vnkozlov]

Looks good.

[openjdk]

@dean-long 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:

8287396: LIR_Opr::vreg_number() and data() can return negative number

Reviewed-by: kvn, chagedorn

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

• a27ba1a: 8287363: null pointer should use NULL instead of 0
• 744b822: 8287073: NPE from CgroupV2Subsystem.getInstance()
• 5848a60: 8286093: java/awt/geom/Path2D/UnitTest.java failed with "RuntimeException: 2D bounds too small"
• 3d2d039: 8287440: Typo in package-info.java of java.util.random
• 36350bf: 8287484: JFR: Seal RecordedObject
• a6e2e22: 8285008: JFR: jdk/jfr/jmx/streaming/TestClose.java failed with "Exception: Expected repository to be empty"
• 2c461ac: 8287492: ProblemList compiler/jvmci/errors/TestInvalidDebugInfo.java
• 6634037: 8287362: FieldAccessWatch testcase failed on AIX platform
• 410a25d: 8286562: GCC 12 reports some compiler warnings
• ed8e8ac: 8284400: Improve XPath exception handling
• ... and 13 more: https://git.openjdk.java.net/jdk/compare/295be6f10ff50eb743c6840e7dcd319fe6f39d0f...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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[dean-long]

I got one timeout in the new test compiler/c1/TestTooManyVirtualRegistersMain.java from JDK-8261235. My change doubles the maximum number of virtual registers allowed, from 0x20000 to 0x40000. That probably explains why the test runs so long. Both numbers seem insanely large. Maybe we should set vreg_max to something more reasonable?

[vnkozlov]

Christian said in #2543:
"There is also a second issue that LIR_OprDesc::vreg_max is too big. It is only used in this bailout code. OprBits::vreg_max is defined over OprBits::data_bits which uses OprBits::non_data_bits. But OprBits::non_data_bits does not consider OprBits::pointer_bits which results in a too large value for LIR_OprDesc::vreg_max and the assertion is hit because we don't bail out, yet. This needs to be fixed as well."

So yes, fix vreg_max.

[dean-long]

I set vreg_max to 10,000. I tried 1,000 first, but there were a few cases during testing where this would cause a bailout on hot methods. With 10,000, only CTW (forced compile of cold methods) and the TestTooManyVirtualRegistersMain.java stress test hit the limit. At 10,000 virtual registers, bailout happens after 8 seconds on a aarch64 debug build.

[vnkozlov]

Good.

[dean-long]

Thanks Vladimir.

[chhagedorn]

That looks more reasonable, thanks for fixing it! Have you also run some additional performance testing?

[dean-long]

Thanks Christian. My first performance run showed some 1-2% regressions on a microbenchmark and a startup benchmark, so I ran it again and the regression disappeared, so I think it was noise. There was no regression for larger benchmarks like SPECjvm2008.

[chhagedorn]

Thanks Dean for evaluating the performance. Then I think it's good to go in.

[dean-long]

/integrate

[openjdk]

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

• 4caf1ef: 8287390: Cleanup Map usage in AuthenticationInfo.requestAuthentication
• 27ad1d5: 8287602: (fs) Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent
• 239ac2a: 8286829: Shenandoah: fix Shenandoah Loom support
• 67ecd30: 8287398: Allow concurrent execution of hotspot docker tests
• 8071b23: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux
• 774928f: 8287625: ProblemList jdk/jshell/HighlightUITest.java on all platforms
• e3791ec: 8287491: compiler/jvmci/errors/TestInvalidDebugInfo.java fails new assert: assert((uint)t < T_CONFLICT + 1) failed: invalid type #
• f8eb7a8: 8287512: continuationEntry.hpp has incomplete definitions
• b2b4ee2: 8287233: Crash in Continuation.enterSpecial: stop: tried to execute native method as non-native
• 168b226: 8282662: Use List.of() factory method to reduce memory consumption
• ... and 57 more: https://git.openjdk.java.net/jdk/compare/295be6f10ff50eb743c6840e7dcd319fe6f39d0f...master

Your commit was automatically rebased without conflicts.

[openjdk]

@dean-long Pushed as commit cdb4768.

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