Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 2 commits into from

Conversation

dean-long
Copy link
Member

@dean-long dean-long commented May 27, 2022

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

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

treat data() as unsigned
@bridgekeeper
Copy link

bridgekeeper bot commented May 27, 2022

👋 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 openjdk bot added the rfr Pull request is ready for review label May 27, 2022
@openjdk
Copy link

openjdk bot commented May 27, 2022

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

@openjdk openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label May 27, 2022
@mlbridge
Copy link

mlbridge bot commented May 27, 2022

Webrevs

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@openjdk
Copy link

openjdk bot commented May 27, 2022

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

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 27, 2022
@dean-long
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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.

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good.

@dean-long
Copy link
Member Author

Thanks Vladimir.

Copy link
Member

@chhagedorn chhagedorn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@dean-long
Copy link
Member Author

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
Copy link
Member

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

@dean-long
Copy link
Member Author

/integrate

@openjdk
Copy link

openjdk bot commented Jun 1, 2022

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 openjdk bot added the integrated Pull request has been integrated label Jun 1, 2022
@openjdk openjdk bot closed this Jun 1, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 1, 2022
@openjdk
Copy link

openjdk bot commented Jun 1, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-compiler hotspot-compiler-dev@openjdk.org integrated Pull request has been integrated
3 participants