Skip to content

8357381: C2: assert(false) failed: should not be here#31037

Open
sarannat wants to merge 1 commit intoopenjdk:masterfrom
sarannat:JDK-8357381
Open

8357381: C2: assert(false) failed: should not be here#31037
sarannat wants to merge 1 commit intoopenjdk:masterfrom
sarannat:JDK-8357381

Conversation

@sarannat
Copy link
Copy Markdown
Contributor

@sarannat sarannat commented May 5, 2026

Issue
The assertion assert(false, "should not be here") in ConnectionGraph::move_inst_mem fires because a StoreB node has StrEquals as a memory user.

Analysis
The main issues starts after the first iteration of iterative escape analysis. As mentioned in JDK-8357381, EA#0 does lock removal. During IGVN after EA#0, the string intrinsic node StrEqual undergoes an ideal transformation (StrIntrinsicNode::Ideal()) which peels its MergeMem input node. At this point StoreB becomes a direct input of StrEquals.

Now EA#1 runs on the transformed graph. Phase 2 of split_unique_types explicitly allows StrEquals as a user of StoreB. In Phase 4, split_unique_types then calls move_inst_mem which is responsible for moving memory users to their memory slices. However, move_inst_mem only handles MergeMem, MemBar, Mem, and Phi as memory user. Since, StrEquals is not handled in move_inst_mem even though it is allowed in Phase 2 of split_unique_types it fires the assertion assert(false, "should not be here").

Solution
In the proposed fix, I have extended move_inst_mem to move string intrinsic nodes that are explicitly allowed in Phase 2 of split_unique_type to their appropriate memory slices.

Testing
Tier1-3 and Github actions

Question to reviewers
Please let me know if this fix looks reasonable.

Thank you @danielogh for the initial analysis.



Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

  • JDK-8357381: C2: assert(false) failed: should not be here (Bug - P3)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31037

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

Using diff file

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

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link
Copy Markdown

bridgekeeper Bot commented May 5, 2026

👋 Welcome back snatarajan! 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
Copy Markdown

openjdk Bot commented May 5, 2026

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk Bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label May 5, 2026
@openjdk
Copy link
Copy Markdown

openjdk Bot commented May 5, 2026

@sarannat 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
Copy link
Copy Markdown

openjdk Bot commented May 5, 2026

The total number of required reviews for this PR has been set to 2 based on the presence of this label: hotspot-compiler. This can be overridden with the /reviewers command.

@sarannat sarannat marked this pull request as ready for review May 5, 2026 17:54
@openjdk openjdk Bot added the rfr Pull request is ready for review label May 5, 2026
@mlbridge
Copy link
Copy Markdown

mlbridge Bot commented May 5, 2026

Webrevs

Comment on lines +4152 to +4153
} else if (use->Opcode() == Op_AryEq || use->Opcode() == Op_StrComp || use->Opcode() == Op_CountPositives ||
use->Opcode() == Op_StrEquals || use->Opcode() == Op_StrIndexOf || use->Opcode() == Op_StrIndexOfChar) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can you add a new method to combine these check into one place and use it here and other places where which check these intrinsics?

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 rfr Pull request is ready for review

Development

Successfully merging this pull request may close these issues.

2 participants