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

JDK-8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer #14490

Closed
wants to merge 5 commits into from

Conversation

enothum
Copy link
Contributor

@enothum enothum commented Jun 15, 2023

Acknowledgments: Thanks to @quadhier for the preliminary work on this issue: #14353

JDK-8309266: TestLoopLimitOverflowDuringCCP.java causes an assertion error (overflow check) in LoopLimitNode::Value. To fix the issue I added a check in LoopLimitNode::Value that verifies that the input nodes are ConI type nodes.

Previously, TestLoopLimitOverflowDuringCCP would cause the assertion error in LoopLimitNode::Value, during PhaseCCP::analyze. The problem originated from PhaseCCP initializing all types to TOP, resulting in the Phi node from int limit = flag ? 1000 : Integer.MAX_VALUE being temporarily considered as Integer.MAX_VALUE. This happens as the Node for the Integer.MAX_VALUE case was already analyzed by CCP while the Node for the 1000 case was still initialized to TOP. When resolving the value of the Phi node, Integer.MAX_VALUE and TOP get merged to Integer.MAX_VALUE, which is then processed by LoopLimitNode::Value as a constant, resulting in the integer overflow.

By checking that the input nodes are ConI nodes in LoopLimitNode::Value, we avoid Phi nodes being misinterpreted during PhaseCCP. If the Phi nodes turn out to be constant they should rather be first transformed to ConI nodes.


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-8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer (Bug - P3)

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14490

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

Using diff file

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

Webrev

Link to Webrev Comment

…sts 2) Verify in LoopLimitNode::Value that the input nodes are ConI type nodes.
@enothum enothum changed the title C2: assert(final_con == (jlong)final_int) failed: final value should be integer JDK-8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer Jun 15, 2023
@bridgekeeper
Copy link

bridgekeeper bot commented Jun 15, 2023

👋 Welcome back enothum! 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
Copy link

openjdk bot commented Jun 15, 2023

@enothum 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 Jun 15, 2023
@enothum enothum marked this pull request as ready for review June 15, 2023 13:05
@openjdk openjdk bot added the rfr Pull request is ready for review label Jun 15, 2023
@mlbridge
Copy link

mlbridge bot commented Jun 15, 2023

Webrevs

@rwestrel
Copy link
Contributor

Let's say CCP is running. Init and limit are not ConINodes at this point but once CCP is over, it will have discovered that they are actually constants so will make them ConINodes. The change you're making will have prevented CCP from propagating the constants through LoopLimitNode making CCP more pessimistic that it needs to be.

@enothum
Copy link
Contributor Author

enothum commented Jun 15, 2023

yes that's an issue, I did not realize that the change could slow the CCP down this way. I guess, defaulting to bottom in case of an overflow might be the better option then.

@enothum
Copy link
Contributor Author

enothum commented Jun 19, 2023

I have now reverted my previous changes.
As new fix, 1) I have changed the assert to only trigger if the input nodes are ConINode and an overflow happens 2) if an overflow is detected, bottom_type() is returned.
This will now not slow down CCP anymore and the test case will execute properly now.

Copy link
Contributor

@rwestrel rwestrel left a comment

Choose a reason for hiding this comment

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

Looks reasonable to me.

return TypeInt::make(final_int);
// Assert checks for overflow only if all input nodes are ConINodes, as during CCP
// there might be a temporary overflow from PhiNodes see JDK-8309266
assert(in(Init)->is_ConI() && in(Limit)->is_ConI() && in(Stride)->is_ConI() \
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need a backslash here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No not really, I just thought the line was getting long

Copy link
Member

Choose a reason for hiding this comment

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

You can wrap lines in asserts without backslashes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahh yes. Not sure why, I probably just used the backslash after having read it in some other parts of the code. Sorry for the confusion from my side

@openjdk
Copy link

openjdk bot commented Jun 19, 2023

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

8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer

Reviewed-by: roland, 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 16 new commits pushed to the master branch:

  • e1906e7: 8310027: Fix -Wconversion warnings in nmethod and compiledMethod related code
  • 4ca548f: 8310326: Incorrect position of the synthetic unnamed class
  • a059576: 8310187: Improve Generational ZGC jtreg testing
  • 9a68ec8: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary ResourceMark
  • 0878872: 8310020: MacroAssembler::call_VM(_leaf) doesn't consistently check for conflict with C calling convention.
  • 79069c5: 8310314: Misplaced "unnamed classes are a preview feature and are disabled by default" error
  • 96a7db7: 8309228: Clarify EXPERIMENTAL flags comment in hotspot/share/runtime/globals.hpp
  • b2e86ae: 8304478: Initial nroff manpage generation for JDK 22
  • 7b45c8f: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups
  • 137a5f7: 8310105: LoongArch64 builds are broken after JDK-8304913
  • ... and 6 more: https://git.openjdk.org/jdk/compare/4229baf9b669ad0af94720cab21a4b80a6ae1c7e...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 (@rwestrel, @chhagedorn) 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 openjdk bot added the ready Pull request is ready to be integrated label Jun 19, 2023
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.

Looks good!

@enothum
Copy link
Contributor Author

enothum commented Jun 20, 2023

/integrate

@enothum
Copy link
Contributor Author

enothum commented Jun 20, 2023

Thanks @chhagedorn and @rwestrel for the feedback and reviews!

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Jun 20, 2023
@openjdk
Copy link

openjdk bot commented Jun 20, 2023

@enothum
Your change (at version 1b3989a) is now ready to be sponsored by a Committer.

@TobiHartmann
Copy link
Member

/sponsor

@openjdk
Copy link

openjdk bot commented Jun 20, 2023

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

  • 4e4e586: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap
  • e1906e7: 8310027: Fix -Wconversion warnings in nmethod and compiledMethod related code
  • 4ca548f: 8310326: Incorrect position of the synthetic unnamed class
  • a059576: 8310187: Improve Generational ZGC jtreg testing
  • 9a68ec8: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary ResourceMark
  • 0878872: 8310020: MacroAssembler::call_VM(_leaf) doesn't consistently check for conflict with C calling convention.
  • 79069c5: 8310314: Misplaced "unnamed classes are a preview feature and are disabled by default" error
  • 96a7db7: 8309228: Clarify EXPERIMENTAL flags comment in hotspot/share/runtime/globals.hpp
  • b2e86ae: 8304478: Initial nroff manpage generation for JDK 22
  • 7b45c8f: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups
  • ... and 7 more: https://git.openjdk.org/jdk/compare/4229baf9b669ad0af94720cab21a4b80a6ae1c7e...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jun 20, 2023
@openjdk openjdk bot closed this Jun 20, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Jun 20, 2023
@openjdk
Copy link

openjdk bot commented Jun 20, 2023

@TobiHartmann @enothum Pushed as commit 4a9cc8a.

💡 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
4 participants