8358534: Bailout in Conv2B::Ideal when type of cmp input is not supported

[JohnTortugo]

Conv2BNode::ideal segfaults in release builds when the type of in(1) is not INT or PTR. Creating a small test case to reproduce the issue is being a bit challenging so this PR only address the issue by bailing out of the method if the input type is unsupported. This other ticket https://bugs.openjdk.org/browse/JDK-8357885 will address creating a regression test for the problem.

Tested with JTREG tier1-3 and Renaissance on Linux x64.

---

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-8358534: Bailout in Conv2B::Ideal when type of cmp input is not supported (Bug - P3)

Reviewers

• Aleksey Shipilev (@shipilev - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25627

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

8358534: Bailout in Conv2B::Ideal when type of cmp input is not supported

Reviewed-by: shade

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

• e235b61: 8357987: [JVMCI] Add support for retrieving all methods of a ResolvedJavaType
• a44a470: 8358515: make cmp-baseline is broken after JDK-8349665
• cc11b7d: 8356128: Correct documentation for --linux-package-deps
• ... and 3 more: https://git.openjdk.org/jdk/compare/c382da579884c28f2765b2c6ba68c0ad4fdcb2ce...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]

@JohnTortugo 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 (2be9f5a4)

[shipilev]

Looks good to me.

[JohnTortugo]

/integrate

[openjdk]

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

• e235b61: 8357987: [JVMCI] Add support for retrieving all methods of a ResolvedJavaType
• a44a470: 8358515: make cmp-baseline is broken after JDK-8349665
• cc11b7d: 8356128: Correct documentation for --linux-package-deps
• ... and 3 more: https://git.openjdk.org/jdk/compare/c382da579884c28f2765b2c6ba68c0ad4fdcb2ce...master

Your commit was automatically rebased without conflicts.

[openjdk]

@JohnTortugo Pushed as commit 704b599.

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

[shipilev]

Wait, hold on. The rule is to wait for 24 hours for Hotspot changes and have at least 2 Reviewers. Unless the change is trivial. This one is simple, but not trivial. So stand by if anyone would ask to back it out.

[shipilev]

@vnkozlov, @TobiHartmann -- FYI, there was a process snag, keep an eye on testing. ^^^

[eme64]

@JohnTortugo If you integrate before 24h, you need to explicitly say that it is trivial, and the reviewer needs to agree.

We in europe were sleeping and did not even have a chance to look at it.

[TobiHartmann]

Also, please don't file JBS issues (without a subcomponent) and integrate them directly. The component triaging teams should at least get a chance to properly triage the issue and set priority etc. Especially when getting close to the rampdown phases, this is required to determine if an issue is even eligible, potentially only with approval, to be fixed in the current release or needs to be deferred.

[TobiHartmann]

I think this is ok for now, assuming that JDK-8357885 will clean this up with a full fix and a regression test.