8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop

[Wanghuang-Huawei]

The reason is :

  BasicType t = store->as_Mem()->memory_type();
  const char* fill_name;
  if (msg == NULL &&
      StubRoutines::select_fill_function(t, false, fill_name) == NULL) {
    msg = "unsupported store";
    msg_node = store;
  }

If the store is a StoreVectorNode ,the BasicType is T_VOID. It seems that we don't need to intrinsify a StoreVectorNode filling here.

I add a new case here to avoid mistake:

  case T_NARROWOOP:
  case T_NARROWKLASS:
  case T_ADDRESS:
+  case T_VOID:
    // Currently unsupported
    return NULL;

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop

Reviewers

• Nils Eliasson (@neliasso - Reviewer)
• Vladimir Kozlov (@vnkozlov - Reviewer)
• Igor Ignatyev (@iignatev - Reviewer)

Contributors

• He Xuejin <hexuejin2@huawei.com>

Download

$ git fetch https://git.openjdk.java.net/jdk16 pull/132/head:pull/132
$ git checkout pull/132

[bridgekeeper]

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

@Wanghuang-Huawei 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

• 07: Full - Incremental (8e1c90d)
• 06: Full - Incremental (cf54002)
• 05: Full - Incremental (b9f1a24)
• 04: Full - Incremental (6efc7ce)
• 03: Full - Incremental (7ec5e23)
• 02: Full - Incremental (ee3797d)
• 01: Full - Incremental (4a50306)
• 00: Full (c1a9301)

[Wanghuang-Huawei]

/contributor add He Xuejin hexuejin2@huawei.com

[openjdk]

@Wanghuang-Huawei
Contributor He Xuejin <hexuejin2@huawei.com> successfully added.

[neliasso]

The fix looks good.

Since JDK 16 is in rampdown phase 2 (http://openjdk.java.net/jeps/3) - this fix will need additional approval before it can be pushed. I will help out with that.

[Wanghuang-Huawei]

The fix looks good.

Since JDK 16 is in rampdown phase 2 (http://openjdk.java.net/jeps/3) - this fix will need additional approval before it can be pushed. I will help out with that.

Thank you for your review and help.

[DamonFool]

Hi @Wanghuang-Huawei , I'm still not clear how to reproduce the bug.

Is it possible to add a jtreg test for this fix?
Thanks.

[vnkozlov]

Need regression test since change is in common code.

[iignatev]

Hi @Wanghuang-Huawei,

given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken TestLoopStoreVector.java from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my pull/132 branch (you will need to replace $copyright-header w/ the appropriate line), feel free to use it as-is or modify.

Thanks,
-- Igor

[iignatev]

/cc hotspot-compiler

[openjdk]

@iignatev
The hotspot-compiler label was successfully added.

[DamonFool]

Hi @Wanghuang-Huawei , I'm still not clear how to reproduce the bug.

Ah, I missed the attachment in the JBS.
Thumbs-up @Wanghuang-Huawei .

[Wanghuang-Huawei]

Hi @Wanghuang-Huawei,

given JDK16 is RDP2 and your patch changes the shared code, you are to integrate an automated jtreg test together with the fix. I've taken TestLoopStoreVector.java from 8260339 and added the minimal required jtreg test description, and double-checked that the test fails on linux-aarch64 w/o the fix and passes w/ it. you can take the jtreg-ified test from my pull/132 branch (you will need to replace $copyright-header w/ the appropriate line), feel free to use it as-is or modify.

Thanks,
-- Igor

Thank you very much. I will push a new commit which contains jtreg test.

[neliasso]

@Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.

[DamonFool]

@Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.

I tried the reproducer on the JBS just now and couldn't reproduce it on x64 either.

[nsjian]

@Wanghuang-Huawei Have you been able to reproduce this on any other platform that linux-aarch64? I'm having trouble reproducing this on x64.

I think x64 has disabled OptimizeFill by default. I can reproduce this with -XX:+OptimizeFill.

[neliasso]

Please add -XX:+OptimizeFill to the regression test

[vnkozlov]

Yes, OptimizeFill is off after 8247307 changes in JDK 16. Add it to @run command (it is C2 flag so you need Ignore* flag):

* @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:+OptimizeFill

[vnkozlov]

Good.
Wait an other day for other people to look.

[openjdk]

@Wanghuang-Huawei 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:

8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop

Co-authored-by: He Xuejin <hexuejin2@huawei.com>
Reviewed-by: neliasso, kvn, iignatyev

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

• e68eac9: 8259765: ZGC: Handle incorrect processor id reported by the operating system
• e28e111: 8260370: C2: LoopLimit node is not eliminated
• 408772c: 8259025: Record compact constructor using Objects.requireNonNull

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@neliasso, @vnkozlov, @iignatev) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[iignatev]

LGTM

[Wanghuang-Huawei]

/integrate

[openjdk]

@Wanghuang-Huawei
Your change (at version 8e1c90d) is now ready to be sponsored by a Committer.

[neliasso]

Looks good.

[neliasso]

I will sponsor this change when 24 hours have passed since the last update.

[neliasso]

/sponsor

[openjdk]

@neliasso @Wanghuang-Huawei Since your change was applied there have been 5 commits pushed to the master branch:

• 8ffdbce: 8260608: add a regression test for 8260370
• 1926765: 8253353: Crash in C2: guarantee(n != NULL) failed: No Node
• e68eac9: 8259765: ZGC: Handle incorrect processor id reported by the operating system
• e28e111: 8260370: C2: LoopLimit node is not eliminated
• 408772c: 8259025: Record compact constructor using Objects.requireNonNull

Your commit was automatically rebased without conflicts.

Pushed as commit a117e11.

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