8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs by rwestrel · Pull Request #24575 · openjdk/jdk

rwestrel · 2025-04-10T15:15:54Z

This is a variant of 8332827. In 8332827, an array access becomes
dependent on a range check CastII for another array access. When,
after loop opts are over, that RC CastII was removed, the array
access could float and an out of bound access happened. With the fix
for 8332827, RC CastIIs are no longer removed.

With this one what happens is that some transformations applied after
loop opts are over widen the type of the RC CastII. As a result, the
type of the RC CastII is no longer narrower than that of its input,
the CastII is removed and the dependency is lost.

There are 2 transformations that cause this to happen:

after loop opts are over, the type of the CastII nodes are widen
so nodes that have the same inputs but a slightly different type can
common.
When pushing a CastII through an Add, if of the type both inputs
of the Adds are non constant, then we end up widening the type
(the resulting Add has a type that's wider than that of the
initial CastII).

There are already 3 types of Cast nodes depending on the
optimizations that are allowed. Either the Cast is floating
(depends_only_test() returns true) or pinned. Either the Cast
can be removed if it no longer narrows the type of its input or
not. We already have variants of the CastII:

if the Cast can float and be removed when it doesn't narrow the type
of its input.
if the Cast is pinned and be removed when it doesn't narrow the type
of its input.
if the Cast is pinned and can't be removed when it doesn't narrow
the type of its input.

What we need here, I think, is the 4th combination:

if the Cast can float and can't be removed when it doesn't narrow
the type of its input.

Anyway, things are becoming confusing with all these different
variants named in ways that don't always help figure out what
constraints one of them operate under. So I refactored this and that's
the biggest part of this change. The fix consists in marking Cast
nodes when their type is widen in a way that prevents them from being
optimized out.

Tobias ran performance testing with a slightly different version of
this change and there was no regression.

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-8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs (Bug - P3)(⚠️ The fixVersion in this issue is [26] but the fixVersion in .jcheck/conf is 27, a new backport will be created when this pr is integrated.)

Reviewers

Galder Zamarreño (@galderz - Author) Review applies to f4076648
Emanuel Peter (@eme64 - Reviewer) Review applies to 93b8b0c5
Christian Hagedorn (@chhagedorn - Reviewer)
Quan Anh Mai (@merykitty - Committer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24575

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-04-10T15:17:03Z

👋 Welcome back roland! 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 · 2025-04-10T15:17:16Z

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

8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs

Reviewed-by: chagedorn, qamai, galder, epeter

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

1bbbce7: 6726690: SwingUtilities.replaceUI*Map() methods do not remove previously installed maps
a5968f9: 8371968: RISC-V: implement AES CBC intrinsics
d36a234: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM
... and 170 more: https://git.openjdk.org/jdk/compare/ef5e744a8136c3d983bdf8721a84fd1488b3c7a8...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 · 2025-04-10T15:17:57Z

@rwestrel 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 · 2025-04-10T15:23:18Z

Webrevs

merykitty · 2025-04-14T11:50:27Z

If a CastII that does not narrow its input has its type being a constant, do you think GVN should transform it into a constant, or such nodes should return the bottom type so that it is not folded into a floating ConNode?

eme64

@rwestrel thanks for looking into this one!

I have not yet deeply studied the PR, but am feeling some confusion about the naming.

I think the DependencyType is really a good step into the right direction, it helps clean things up.

I'm wondering if we should pick either depends_only_on_test or pinned, and use it everywhere consistently. Having both around as near synonymes (antonymes?) is a bit confusing for me.

I'll look into the code more later.

eme64 · 2025-04-23T10:49:41Z

src/hotspot/share/opto/castnode.cpp

+const ConstraintCastNode::DependencyType ConstraintCastNode::RegularDependency(true, true, "regular dependency"); // not pinned, narrows type
+const ConstraintCastNode::DependencyType ConstraintCastNode::WidenTypeDependency(true, false, "widen type dependency"); // not pinned, doesn't narrow type
+const ConstraintCastNode::DependencyType ConstraintCastNode::StrongDependency(false, true, "strong dependency"); // pinned, narrows type
+const ConstraintCastNode::DependencyType ConstraintCastNode::UnconditionalDependency(false, false, "unconditional dependency"); // pinned, doesn't narrow type


Is there really a good reason to have the names Regular, WidenType, Strong and Unconditional? Did we just get used to these names over time, or do they really have a good reason for existance. They just don't really mean that much to me. Calling them (non)pinned and (non)narrowing would make more sense to me.

So NonPinnedNarrowingDependency, NonPinnedNonNarrowingDependeny, PinnedNarrowingDependency and NonPinnedNonNarrowingDependency?

Or to avoid using a negation for the one that's the weakest dependency:

FloatingNarrowingDependency, FloatingNonNarrowingDependency, NonFloatingNarrowingDependency and NonFloatingNonNarrowingDependency ?

What do you think @eme64 ?

Either of these sound great :)

eme64 · 2025-04-23T10:51:16Z

src/hotspot/share/opto/castnode.hpp

+    bool depends_only_on_test() const {
+      return _depends_only_on_test;
+    }


Is this synonimous to non_pinning? Might that be more descriptive?

eme64 · 2025-04-23T10:53:53Z

src/hotspot/share/opto/castnode.hpp

+    const bool _depends_only_on_test; // Does this Cast depends on its control input or is it pinned?
+    const bool _narrows_type; // Does this Cast narrows the type i.e. if input type is narrower can it be removed?


I think it would be good to have a really strong definition of these two, because everything else depends on it.

I would recommend to either use depends_only_on_test as the "primary" word here, or else pinned. But then try to consistently use the chosen one everywhere. Just to avoid confusion with these near synonymes.

It may also be helpful to have an example for each of the 4 combinations, just as an illustration of your definitions.

rwestrel · 2025-04-24T09:12:39Z

If a CastII that does not narrow its input has its type being a constant, do you think GVN should transform it into a constant, or such nodes should return the bottom type so that it is not folded into a floating ConNode?

The current patch constant folds the CastII in that case. I could write a test case where that's an issue (it causes an out of bound load to float above the range check it depends on). I'm working on an update to the patch to address this.

rwestrel · 2025-04-24T09:15:21Z

@emea thanks for the comments. As mentioned in another comment, I'm in the process of reworking the patch.

I'm wondering if we should pick either depends_only_on_test or pinned, and use it everywhere consistently. Having both around as near synonymes (antonymes?) is a bit confusing for me.

depends_only_on_test comes from Node::depends_only_on_test.

TobiHartmann · 2025-05-13T08:49:56Z

Just wondering, since we are getting closer to RDP 1 for JDK 25 (June 05, 2025), should we defer this to JDK 26?

rwestrel · 2025-05-13T08:52:31Z

Just wondering, since we are getting closer to RDP 1 for JDK 25 (June 05, 2025), should we defer this to JDK 26?

Deferring makes sense. This is a corner case anyway. I've been reworking the patch and it's getting more complicated so it will likely need more time for reviews.

TobiHartmann · 2025-05-13T08:55:16Z

Sounds good, I'll defer it to JDK 26 then. Thanks for the quick reply!

openjdk · 2025-05-13T08:57:01Z

@rwestrel this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8354282
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

bridgekeeper · 2025-06-10T10:41:11Z

@rwestrel This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2025-07-08T11:03:16Z

@rwestrel This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

rwestrel · 2025-07-08T11:07:22Z

/keepalive

openjdk · 2025-07-08T11:08:50Z

@rwestrel This command can only be used in open pull requests.

rwestrel · 2025-07-08T11:09:59Z

/open

openjdk · 2025-07-08T11:10:07Z

@rwestrel This pull request is now open

bridgekeeper · 2025-08-05T15:07:19Z

@rwestrel This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2025-09-02T15:40:19Z

@rwestrel This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

chhagedorn

Thanks for the update, it looks good to me! If @eme64 also agrees with the latest patch, we can submit some testing and then hopefully get it in right before the fork.

chhagedorn · 2025-12-02T13:50:13Z

src/hotspot/share/opto/castnode.hpp

+    const DependencyType& with_pinned_dependency() const {
+      if (_narrows_type) {
+        return NonFloatingNarrowing;
+      }
+      return NonFloatingNonNarrowing;
+    }


Yes, that's true. I was also unsure about whether we should stick with one or just allow both interchangeably. I guess since there are so many uses, we can just move forward with what you have now and still come back to clean it up if necessary - we can always do that.

chhagedorn · 2025-12-02T13:50:33Z

src/hotspot/share/opto/castnode.hpp

+    // used when a floating node is sunk out of loop: we don't want the cast that forces the node to be out of loop to
+    // be removed in any case otherwise the sunk node floats back into the loop.
+    static const DependencyType NonFloatingNonNarrowing;
+


Thanks for taking it over :-)

src/hotspot/share/opto/castnode.hpp

eme64

@rwestrel Nice work! We not just only fixed the bug but made the concepts much clearer. This makes me very happy 😊

merykitty · 2025-12-02T17:32:09Z

src/hotspot/share/opto/castnode.hpp

+
+    // All the possible combinations of floating/narrowing with example use cases:
+
+    // Use case example: Range Check CastII


I believe this is incorrect, a range check should be floating non-narrowing. It is only narrowing if the length of the array is a constant. It is because this cast encodes the dependency on the condition index u< length. This condition cannot be expressed in terms of Type unless length is a constant.

Range check CastII were added to protect the ConvI2L in the address expression on 64 bits. The problem there was, in some cases, that the ConvI2L would float above the range check (because ConvI2L has no control input) and could end up with an out of range input (which in turn would cause the ConvI2L to become top in places where it wasn't expected).
So CastII doesn't carry the control dependency of an array access on its range check. That dependency is carried by the MemNode which has its control input set to the range check.
What you're saying, if I understand it correctly, would be true if the CastII was required to prevent an array Load from floating. But that's not the case.

Got it, sorry I misunderstood!

src/hotspot/share/opto/castnode.hpp

Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

rwestrel · 2025-12-08T14:49:41Z

@merykitty @eme64 @chhagedorn thanks for the reviews
Does testing need to be run on this before I integrate?

eme64 · 2025-12-08T15:48:28Z

@rwestrel I'll run some testing now ...

eme64 · 2025-12-09T07:53:54Z

@chhagedorn I see that an internal IR test is failing - one that you added a while back. Could you have a look what may have gone wrong?

chhagedorn · 2025-12-09T14:07:22Z

I had a look and it seems that the internal test is relying on a CastII node to be removed after loop opts, when we widen CastII nodes, to trigger an ideal optimization. That is no longer the case with this patch because we keep the CastII node in the graph. The fix would be to improve the ideal optimization to look through cast nodes. However, this feels out of scope, especially since this PR is a bug fix for JDK 26.

I therefore propose to fix the internal test before integrating this PR and then follow up with an RFE to fix the ideal optimization. I can take care of this and let you know once this is done.

rwestrel · 2025-12-09T14:59:43Z

I therefore propose to fix the internal test before integrating this PR and then follow up with an RFE to fix the ideal optimization. I can take care of this and let you know once this is done.

That sounds good to me. Should I take care of the ideal transformation? Let me know when the internal test is so I can proceed with the integration.

chhagedorn · 2025-12-09T15:23:52Z

Thanks Roland! I'll let you know and file a follow-up RFE and assign it to you. I will dump all the relevant information in there with a test case.

chhagedorn · 2025-12-09T17:56:32Z

The internal test is fixed and sanity testing passed - you can move forward with integrating this PR :-)

rwestrel · 2025-12-10T08:05:30Z

@chhagedorn @eme64 @merykitty thanks for the reviews and testing

rwestrel · 2025-12-10T08:05:36Z

/integrate

openjdk · 2025-12-10T08:06:34Z

@rwestrel This pull request has not yet been marked as ready for integration.

rwestrel · 2025-12-10T08:43:04Z

/integrate

openjdk · 2025-12-10T08:45:21Z

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

1bbbce7: 6726690: SwingUtilities.replaceUI*Map() methods do not remove previously installed maps
a5968f9: 8371968: RISC-V: implement AES CBC intrinsics
d36a234: 8368701: CDS VerifierTest_1A.java failed on machines with 512 GB RAM
... and 170 more: https://git.openjdk.org/jdk/compare/ef5e744a8136c3d983bdf8721a84fd1488b3c7a8...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-12-10T08:45:29Z

@rwestrel Pushed as commit 00068a8.

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

rwestrel · 2025-12-18T08:28:55Z

/backport :jdk26

openjdk · 2025-12-18T08:29:57Z

@rwestrel the backport was successfully created on the branch backport-rwestrel-00068a80-jdk26 in my personal fork of openjdk/jdk. To create a pull request with this backport targeting openjdk/jdk:jdk26, just click the following link:

➡️ Create pull request

The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 00068a80 from the openjdk/jdk repository.

The commit being backported was authored by Roland Westrelin on 10 Dec 2025 and was reviewed by Christian Hagedorn, Quan Anh Mai, Galder Zamarreño and Emanuel Peter.

Thanks!

If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk:

$ git fetch https://github.com/openjdk-bots/jdk.git backport-rwestrel-00068a80-jdk26:backport-rwestrel-00068a80-jdk26
$ git checkout backport-rwestrel-00068a80-jdk26
# make changes
$ git add paths/to/changed/files
$ git commit --message 'Describe additional changes made'
$ git push https://github.com/openjdk-bots/jdk.git backport-rwestrel-00068a80-jdk26

fix & test

f407664

rwestrel marked this pull request as ready for review April 10, 2025 15:17

openjdk bot added hotspot-compiler hotspot-compiler-dev@openjdk.org rfr Pull request is ready for review labels Apr 10, 2025

galderz approved these changes Apr 15, 2025

View reviewed changes

eme64 suggested changes Apr 23, 2025

View reviewed changes

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label May 13, 2025

bridgekeeper bot closed this Jul 8, 2025

openjdk bot reopened this Jul 8, 2025

bridgekeeper bot closed this Sep 2, 2025

Merge branch 'master' into JDK-8354282

d88b23f

chhagedorn approved these changes Dec 2, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Dec 2, 2025

eme64 reviewed Dec 2, 2025

View reviewed changes

src/hotspot/share/opto/castnode.hpp Show resolved Hide resolved

eme64 approved these changes Dec 2, 2025

View reviewed changes

merykitty reviewed Dec 2, 2025

View reviewed changes

Update src/hotspot/share/opto/castnode.hpp

cab4442

Co-authored-by: Emanuel Peter <emanuel.peter@oracle.com>

openjdk bot removed the ready Pull request is ready to be integrated label Dec 5, 2025

review

4a877c4

merykitty approved these changes Dec 8, 2025

View reviewed changes

chhagedorn approved these changes Dec 10, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Dec 10, 2025

openjdk bot added the integrated Pull request has been integrated label Dec 10, 2025

openjdk bot closed this Dec 10, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 10, 2025

		const bool _depends_only_on_test; // Does this Cast depends on its control input or is it pinned?
		const bool _narrows_type; // Does this Cast narrows the type i.e. if input type is narrower can it be removed?


		// All the possible combinations of floating/narrowing with example use cases:

		// Use case example: Range Check CastII

Conversation

rwestrel commented Apr 10, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Apr 10, 2025

Uh oh!

openjdk bot commented Apr 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Apr 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Apr 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

merykitty commented Apr 14, 2025

Uh oh!

eme64 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwestrel commented Apr 24, 2025

Uh oh!

rwestrel commented Apr 24, 2025

Uh oh!

TobiHartmann commented May 13, 2025

Uh oh!

rwestrel commented May 13, 2025

Uh oh!

TobiHartmann commented May 13, 2025

Uh oh!

openjdk bot commented May 13, 2025

Uh oh!

bridgekeeper bot commented Jun 10, 2025

Uh oh!

bridgekeeper bot commented Jul 8, 2025

Uh oh!

rwestrel commented Jul 8, 2025

Uh oh!

openjdk bot commented Jul 8, 2025

Uh oh!

rwestrel commented Jul 8, 2025

Uh oh!

openjdk bot commented Jul 8, 2025

Uh oh!

bridgekeeper bot commented Aug 5, 2025

Uh oh!

bridgekeeper bot commented Sep 2, 2025

Uh oh!

chhagedorn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

eme64 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwestrel commented Apr 10, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Apr 10, 2025 •

edited

Loading

openjdk bot commented Apr 10, 2025 •

edited

Loading

mlbridge bot commented Apr 10, 2025 •

edited

Loading

chhagedorn commented Dec 9, 2025 •

edited

Loading