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

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)

Reviewers

Galder Zamarreño (@galderz - Author) 🔄 Re-review required (review applies to f4076648)

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

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

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.

rwestrel · 2025-10-01T12:18:51Z

/open

openjdk · 2025-10-01T12:19:40Z

@rwestrel This pull request is now open

rwestrel · 2025-10-01T12:31:36Z

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 allows constant folding. I could (since I last commented on this PR) write test cases for which this causes issues. Disallowing constant folding seems too strict to me. I propose the issues related to constant folding be handled in a separate PR.

rwestrel · 2025-10-02T09:03:56Z

I pushed an update with the renaming suggested by @eme64 and an extra comment with example use cases

openjdk · 2025-10-02T09:05:39Z

@rwestrel graal, hotspot, shenandoah have been added to this pull request based on files touched in new commit(s).

bridgekeeper · 2025-10-30T10:10:05Z

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

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

merge

c509ef5

openjdk bot reopened this Oct 1, 2025

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Oct 1, 2025

rwestrel added 3 commits October 1, 2025 14:50

renaming

14294ad

infinite loop in gvn fix

620000e

review

aff5894

openjdk bot added graal graal-dev@openjdk.org hotspot hotspot-dev@openjdk.org shenandoah shenandoah-dev@openjdk.org labels Oct 2, 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?

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

Are you sure you want to change the base?

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

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

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!

eme64 Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

rwestrel Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

eme64 Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

eme64 Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

eme64 Apr 23, 2025

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!

rwestrel commented Oct 1, 2025

Uh oh!

openjdk bot commented Oct 1, 2025

Uh oh!

rwestrel commented Oct 1, 2025

Uh oh!

rwestrel commented Oct 2, 2025

Uh oh!

openjdk bot commented Oct 2, 2025

Uh oh!

rwestrel commented Apr 10, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Apr 10, 2025 •

edited

Loading

mlbridge bot commented Apr 10, 2025 •

edited

Loading