8290432: C2 compilation fails with assert(node->_last_del == _last) failed: must have deleted the edge just produced #9695

y1yang0 · 2022-07-31T09:28:59Z

Hi, can I have a review for this patch? JDK-8273585 recognized the form of Phi->CastII->AddI as additional parallel induction variables. In the following program:

class Test {
    static int dontInline() {
        return 0;
    }

    static long test(int val, boolean b) {
        long ret = 0;
        long dArr[] = new long[100];
        for (int i = 15; 293 > i; ++i) {
            ret = val;
            int j = 1;
            while (++j < 6) {
                int k = (val--);
                for (long l = i; 1 > l; ) {
                    if (k != 0) {
                        ret += dontInline();
                    }
                }
                if (b) {
                    break;
                }
            }
        }
        return ret;
    }

    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            test(0, false);
        }
    }
}

val is incorrectly matched with the new parallel IV form:

And C2 further replaces it with newly added nodes, which finally leads the crash:

I think we can add more constraints to the new form. The form of Phi->CastXX->AddX appears when using Preconditions.checkIndex, and it would be recognized as additional IV when 1) Phi != phi2, 2) CastXX is controlled by RangeCheck(to reflect changes in Preconditions checkindex intrinsic)

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-8290432: C2 compilation fails with assert(node->_last_del == _last) failed: must have deleted the edge just produced

Reviewers

Vladimir Kozlov (@vnkozlov - Reviewer)
Tobias Hartmann (@TobiHartmann - Reviewer)
Christian Hagedorn (@chhagedorn - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9695

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

Using diff file

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

…ailed: must have deleted the edge just produced

y1yang0 · 2022-08-01T03:22:06Z

/rfr

bridgekeeper · 2022-08-01T12:22:21Z

👋 Welcome back yyang! 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 · 2022-08-01T12:46:58Z

@kelthuzadx Unknown command rfr - for a list of valid commands use /help.

openjdk · 2022-08-01T12:48:54Z

@kelthuzadx 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 · 2022-08-01T12:55:47Z

Webrevs

vnkozlov

From your test I assume internal loop for (long l= is processed. But val is updated outside it. Its AddI node should not be part of loop's body. Could you explain?

vnkozlov · 2022-08-04T17:05:31Z

src/hotspot/share/opto/loopnode.cpp

+    if (incr2->in(1)->is_ConstraintCast()) {
+      if (!incr2->in(1)->in(0)->is_RangeCheck()) {


You can use && instead of nested condition.

vnkozlov · 2022-08-04T17:07:30Z

src/hotspot/share/opto/loopnode.cpp

        !incr2->in(2)->is_Con())
      continue;


Since you touch near code, please update style in these lines too to use {}.

The whole function is formatted.

y1yang0 · 2022-08-05T09:05:58Z

Hi @vnkozlov, thanks for your review. Here is the (almost) complete IR before replacing additional parallel IVs:

Before that, some loop optimizations are applied: [15,293) and [2,6) are recognized as counted loops, and the latter loop is maximally unrolled. Loop unswitching is applied when C2 saw if (b). The transformed program looks like:

static long test(int val, boolean b) {
    long ret = 0;
    long dArr[] = new long[100];
    if (b) {
        for (int i = 15; 293 > i; ++i) {
            ret = val;
            val--;
        }
    } else {
        for (int i = 15; 293 > i; ++i) {
            ret = val;
            val-=4
        }
    }
    return ret;
}

Their corresponding IR are as follows:

Phi#564 and Phi#125 represent val in two unswitched loops, respectively. val is actually part of loop body.

vnkozlov · 2022-08-05T22:13:50Z

src/hotspot/share/opto/loopnode.cpp

+      // The form of Phi->CastXX->AddX appears when using Preconditions.checkIndex, and it would
+      // be recognized as additional IV when 1) Phi != phi2, 2) CastXX is controlled by RangeCheck
+      // (to reflect changes in LibraryCallKit::inline_preconditions_checkIndex)


Thank you for updating comment. But it still do not say which issue you are trying to avoid. Yes, this pattern can be generated by inline_preconditions_checkIndex.
Currently your check skip search for parallel IV if CastII is NOT controlled by RangeCheck!
But the comment in the BODY of check talks about using parallel IV.
It is contradicting.
Aslo 1) Phi != phi2 says nothing to me - your check does not have such condition.

Why not just say that we should skip AddI->CastII->Phi case if CastII is not controlled by local RangeCheck.

Why not just say that we should skip AddI->CastII->Phi case if CastII is not controlled by local RangeCheck.

Yes, this is exactly what I want to say. Maybe I should update comments.

vnkozlov · 2022-08-05T22:33:48Z

About test's loops. I see that C2 recognized that for (long l = i; 1 > l; ) is not executed because i >= 15.
Then while (++j < 6) will be executed only once if b == true - C2 unswitch it with result of method code you showed.
Good.

BUT. val is long type. Why we are trying to use it as IV instead of existing int i? I think the issue is not in Cast node. There is mixture of long and int types here which confuses loop optimizer. What if val was int type?

y1yang0 · 2022-08-06T05:18:13Z

BUT. val is long type. Why we are trying to use it as IV instead of existing int i? I think the issue is not in Cast node. There is mixture of long and int types here which confuses loop optimizer. What if val was int type?

val is type of int! And we are not trying to use it instead of existing int i, we are using both of them as IV.

TobiHartmann

Could you explain why it's an issue in this case if the control input of the CastII is not a range check?

TobiHartmann · 2022-08-09T12:51:33Z

src/hotspot/share/opto/loopnode.cpp


+    if (incr2->in(1)->is_ConstraintCast() && !incr2->in(1)->in(0)->is_RangeCheck()) {
+      // Skip AddI->CastII->Phi case if CastII is not controlled by local RangeCheck
+      // to reflect changes in LibraryCallKit::inline_preconditions_checkIndex


In the valid case, isn't the ConstraintCast control input incr2->in(1)->in(0) the IfTrue projection of the RangeCheck?

I would remove the second line because it's not clear which "changes" in LibraryCallKit::inline_preconditions_checkIndex it is referring to.

Suggested change

// to reflect changes in LibraryCallKit::inline_preconditions_checkIndex

It's still not clear to me how the incr2->in(1)->in(0)->is_RangeCheck() condition can ever be true. How can the control input of a ConstraintCast be a RangeCheck? Shouldn't there be a projection node in-between?

I missed this comment before... incr2->in(1)->in(0)->in(0)->is_RangeCheck() is really what I want. I also double-checked this.

incr2->in(1)->in(0)->is_RangeCheck() prevents JDK-8273585 from optimization - 15s
incr2->in(1)->in(0)->in(0)->is_RangeCheck() allows JDK-8273585 to optimize further - 8s

TobiHartmann · 2022-08-09T13:00:00Z

I think we should add an IR verification test for JDK-8273585.

vnkozlov · 2022-08-09T16:57:30Z

BUT. val is long type. Why we are trying to use it as IV instead of existing int i? I think the issue is not in Cast node. There is mixture of long and int types here which confuses loop optimizer. What if val was int type?

val is type of int! And we are not trying to use it instead of existing int i, we are using both of them as IV.

Right. I mixed ret long type with val.

vnkozlov · 2022-08-09T17:16:02Z

I still think the issue is in some other place. Your change just avoiding the case which triggers it. The java code is legal and compiling next code did not trigger nay issues:

    static long test(int val, boolean b) {
         long ret = 0;
         for (int i = 15; 293 > i; ++i) {
             ret = val;
             val--;
         }
         return ret;
     }

Actually I was not able to reproduce the issue with included test.

y1yang0 · 2022-08-24T02:22:48Z

I still think the issue is in some other place.

Why? Can you clarify more? The root cause seems clear: the unexpected Add->CastII->Phi pattern was matched due to changes in JDK-8273585 and finally leads the crash.

y1yang0 · 2022-08-24T02:23:33Z

I think we should add an IR verification test for JDK-8273585.

Yes, we need a verification test for it. I'll do this later.

TobiHartmann · 2022-09-08T07:19:10Z

Why? Can you clarify more?

As I mentioned above, I don't understand how your newly added condition is supposed to work.

bridgekeeper · 2022-10-06T10:49:49Z

@kelthuzadx 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 add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

TobiHartmann · 2022-10-26T06:49:43Z

Comment to keep this open. @kelthuzadx, any update on this?

y1yang0 · 2022-11-16T02:28:53Z

Why? Can you clarify more?

As I mentioned above, I don't understand how your newly added condition is supposed to work.

@vnkozlov @TobiHartmann I reviewed the above comments again. I think the proposed fix is good. According to my analysis at #9695 (comment) , we have a parallel IV which formed as Add->CastII->Phi, the birth of the form looks good, and this pattern is only legal after JDK-8273585. In that case, Add->CastII->Phi parallel IV was generated by Preconditions.checkIndex, CastII was controlled by RangeCheck. In the proposed fix, I'm trying to avoid to recognize similar pattern if CastII was not controlled by RangeCheck.

As far as this fix itself is concerned, I think the whole process is reasonable, i.e. we accept that form as parallel IV only when it was generated by library_call_preconditions_checkindex. The only thing I'm not sure about is whether this Add-CastII-Phi form itself is really reasonable as an IV, which is why I think adding an IR verification test for JDK-8273585 is reasonable, I will go back to investigate that again after this patch, what do you think?

TobiHartmann · 2022-11-16T12:25:21Z

test/hotspot/jtreg/compiler/c2/TestUnexpectedParallelIV.java

+/**
+ * @test
+ * @bug 8290432
+ * @summary Unexpected parallel induction variable pattern was recongized


This test does not reproduce the issue for me, whereas Test-2.java still works.

You can reset to JDK-8273585, TestUnexpectedParallelIV.java reproduces the crash. Test-2.java can always reproduce without resetting commits. I added both of them as test cases.

TobiHartmann

The new version looks reasonable to me but please merge the two tests into one. There is also a jcheck whitespace error.

If you don't intend to add an IR verification test for JDK-8273585 with this fix, please file at least a follow-up enhancement.

y1yang0 · 2022-11-21T02:27:30Z

I filed adding IR verification test as https://bugs.openjdk.org/browse/JDK-8297307.

TobiHartmann

Looks good to me.

TobiHartmann

Looks good to me.

openjdk · 2022-11-21T06:14:38Z

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

8290432: C2 compilation fails with assert(node->_last_del == _last) failed: must have deleted the edge just produced

Reviewed-by: kvn, thartmann, 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 1797 new commits pushed to the master branch:

0d2a9ee: 8298142: Update internal comment on language features in SourceVersion
203251f: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
1e46832: 8297602: Compiler crash with type annotation and generic record during pattern matching
b0e5432: 8297687: new URI(S,S,S,S) throws exception with incorrect index position reported in the error message
2243646: 8298145: Remove ContiguousSpace::capacity
84b927a: 8296024: Usage of DirectBuffer::address should be guarded
a9e6c62: 8297186: G1 triggers unnecessary full GCs when heap utilization is low
4458de9: 8297172: Fix some issues of auto-vectorization of Long.bitCount/numberOfTrailingZeros/numberOfLeadingZeros()
a613998: 8297689: Fix incorrect result of Short.reverseBytes() call in loops
f8f4630: 8297963: Partially fix string expansion issues in UTIL_DEFUN_NAMED and related macros
... and 1787 more: https://git.openjdk.org/jdk/compare/af86cd3d8c0f8a874d1b738ad0caeeb7cd4c61d0...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.

y1yang0 · 2022-11-21T13:15:19Z

@vnkozlov Can I have a second review? Thanks!

vnkozlov

I may ask to do our internal performance testing for this change too before approval.

y1yang0 · 2022-11-29T09:51:46Z

I may ask to do our internal performance testing for this change too before approval.

Do you mean... oracle internal performance testing or opensource microbenchmark inside openjdk? For the former one, may I ask your help to do that? Thanks. (For the later one, I tested JDK-8273585 attached test, and it works well. After this patch, it takes 8s.)

TobiHartmann · 2022-11-29T12:03:01Z

I'll run some performance testing in our system and report back once it passed.

TobiHartmann · 2022-12-01T06:28:04Z

Performance results look good (no measurable difference). A second review would be good though.

TobiHartmann · 2022-12-01T06:28:13Z

/reviewers 2

openjdk · 2022-12-01T06:28:58Z

@TobiHartmann
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

chhagedorn · 2022-12-01T08:23:41Z

Do we really need this bailout? From your very first picture, it does not seem wrong to replace 125 Phi - the only problem is that 465 CastII also happens to have 432 CountedLoop as control input. This leads to the crash because we are removing two outputs of 432 CountedLoop at once which is not valid and previously unexpected (before JDK-8273585) . Couldn't we instead just update replace_parallel_iv() in such a way that it can handle this particular case of removing two outputs at once from the counted loop?

y1yang0 · 2022-12-01T11:28:08Z

it does not seem wrong to replace 125 Phi - the only problem is that 465 CastII also happens to have 432 CountedLoop as control input.

If replacing Phi#125 is acceptable, we need to reach a consensus that the form of Add->CastII->Phi can be considered as parallel IV, which is not valid before JDK-8273585. Prior to that, we only considered variables of the form X += constant(Add->Phi) to be IV.

I’m not sure whether we have such a consensus that the form of Add->CastII->Phi is considered a parallel IV beside a special case? If not, a conservative approach would be to reject it as a parallel IV at the beginning, in this way, subsequent Phi replacement will not occur.

chhagedorn

If replacing Phi#125 is acceptable, we need to reach a consensus that the form of Add->CastII->Phi can be considered as parallel IV

I think it should be safe and we've already done that since JDK-8273585 and haven't seen a crash related to that idea. But given how close we are to the fork, I suggest to go with your bailout fix for JDK 20 which is safer (and performance testing done by Tobias looks good). In this way, we really only optimize the pattern originally intended in JDK-8273585.

For the general case of allowing any cast node, I suggest to file an RFE and investigate again if that is possible/correct. I have the feeling that it is but it would be better to defer that to JDK 21. What do you think?

Thanks,
Christian

TobiHartmann · 2022-12-01T12:16:48Z

That makes sense, you can re-use/extend JDK-8297307 for that.

Vladimir should also have a look at this again.

y1yang0 · 2022-12-01T12:26:51Z

For the general case of allowing any cast node, I suggest to file an RFE and investigate again if that is possible/correct.

Thanks, Christian

I think it’s really reasonable. As Tobias said, we can reuse https://bugs.openjdk.org/browse/JDK-8297307 for this purpose. Thanks!

vnkozlov · 2022-12-06T18:00:21Z

That makes sense, you can re-use/extend JDK-8297307 for that.

Vladimir should also have a look at this again.

I agree with this suggestion.

y1yang0 · 2022-12-07T03:05:06Z

/integrate

openjdk · 2022-12-07T03:08:22Z

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

ce89673: 8297804: (tz) Update Timezone Data to 2022g
62baff5: 8298221: Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64
16a5901: 8298214: ProblemList java/util/concurrent/forkjoin/AsyncShutdownNow.java
b4da0ee: 8296507: GCM using more memory than necessary with in-place operations
cd2182a: 8295724: VirtualMachineError: Out of space in CodeCache for method handle intrinsic
2cdc019: 8298178: Update to use jtreg 7.1.1
79d163d: 8293412: Remove unnecessary java.security.egd overrides
ea83cb9: 8297450: ScaledTextFieldBorderTest.java fails when run with -show parameter
336d230: 8297958: NMT: Display peak values
0d2a9ee: 8298142: Update internal comment on language features in SourceVersion
... and 1796 more: https://git.openjdk.org/jdk/compare/af86cd3d8c0f8a874d1b738ad0caeeb7cd4c61d0...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-12-07T03:08:39Z

@y1yang0 Pushed as commit acf96c6.

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

8290432: C2 compilation fails with assert(node->_last_del == _last) f…

e91c448

…ailed: must have deleted the edge just produced

y1yang0 marked this pull request as ready for review August 1, 2022 02:18

openjdk bot added the rfr Pull request is ready for review label Aug 1, 2022

openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Aug 1, 2022

vnkozlov reviewed Aug 4, 2022

View reviewed changes

format

c44af03

vnkozlov reviewed Aug 5, 2022

View reviewed changes

update comment

7c69d8f

TobiHartmann reviewed Aug 9, 2022

View reviewed changes

TobiHartmann reviewed Nov 16, 2022

View reviewed changes

skip IfProj

4cce45e

openjdk bot removed the rfr Pull request is ready for review label Nov 17, 2022

TobiHartmann reviewed Nov 17, 2022

View reviewed changes

openjdk bot added the rfr Pull request is ready for review label Nov 21, 2022

TobiHartmann approved these changes Nov 21, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Nov 21, 2022

vnkozlov reviewed Nov 22, 2022

View reviewed changes

openjdk bot removed the ready Pull request is ready to be integrated label Dec 1, 2022

chhagedorn approved these changes Dec 1, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Dec 1, 2022

vnkozlov approved these changes Dec 6, 2022

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Dec 7, 2022

openjdk bot closed this Dec 7, 2022

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

y1yang0 deleted the JDK-8290432 branch December 7, 2022 03:08

		if (incr2->in(1)->is_ConstraintCast()) {
		if (!incr2->in(1)->in(0)->is_RangeCheck()) {

8290432: C2 compilation fails with assert(node->_last_del == _last) failed: must have deleted the edge just produced #9695

8290432: C2 compilation fails with assert(node->_last_del == _last) failed: must have deleted the edge just produced #9695

Uh oh!

Conversation

y1yang0 commented Jul 31, 2022 • 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!

y1yang0 commented Aug 1, 2022

Uh oh!

bridgekeeper bot commented Aug 1, 2022

Uh oh!

openjdk bot commented Aug 1, 2022

Uh oh!

openjdk bot commented Aug 1, 2022

Uh oh!

mlbridge bot commented Aug 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

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

y1yang0 commented Aug 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

vnkozlov commented Aug 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

y1yang0 commented Aug 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

y1yang0 Nov 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TobiHartmann commented Aug 9, 2022

Uh oh!

vnkozlov commented Aug 9, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vnkozlov commented Aug 9, 2022

Uh oh!

y1yang0 commented Aug 24, 2022

Uh oh!

y1yang0 commented Aug 24, 2022

Uh oh!

TobiHartmann commented Sep 8, 2022

Uh oh!

bridgekeeper bot commented Oct 6, 2022

Uh oh!

TobiHartmann commented Oct 26, 2022

Uh oh!

y1yang0 commented Nov 16, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

y1yang0 commented Jul 31, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Aug 1, 2022 •

edited

Loading

y1yang0 commented Aug 5, 2022 •

edited

Loading

vnkozlov commented Aug 5, 2022 •

edited

Loading

y1yang0 commented Aug 6, 2022 •

edited

Loading

y1yang0 Nov 17, 2022 •

edited

Loading

vnkozlov commented Aug 9, 2022 •

edited

Loading

y1yang0 commented Nov 16, 2022 •

edited

Loading

openjdk bot commented Nov 21, 2022 •

edited

Loading

vnkozlov left a comment •

edited

Loading

y1yang0 commented Dec 1, 2022 •

edited

Loading