JDK-8322854: Incorrect rematerialization of scalar replaced objects in C2

[JohnTortugo]

Current implementation of PhaseMacroExpand::value_from_mem returns return _igvn.zerocon(ft); when it hits a sentinel while searching for a memory operation on a given slice. One of the sentinels is the memory input of the allocate node origin of the memory slice. Therefore, value_from_mem may return zeroconf(ft) if sfpt_mem is the same memory edge used by the Allocate node origin of the memory slice being traversed.

The scalar replacement implementation uses value_from_mem during creation of metadata describing object scalar replaced (see PhaseMacroExpand::create_scalarized_object_description). The create_scalarized_object_description method is also used as part of RAM optimization implementation. The RAM optimization targets Phi nodes and therefore a memory graph loop created by a memory phi node is possible to seen as part of the transformation. See image below:

This pattern doesn't show up when scalarizing objects that don't participate in allocation merges.

To fix the issue I changed the code in value_from_mem to instead of using the input memory edge of the Allocate as a stop condition, it will now use the projection memory edge of the Allocate.

Tested locally on windows, mac and linux x86_64 with JTREG tier1-3 and didn't observe any 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-8322854: Incorrect rematerialization of scalar replaced objects in C2 (Bug - P2)

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)
• Tobias Hartmann (@TobiHartmann - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 17562

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

• 03: Full - Incremental (27a81960)
• 02: Full - Incremental (22ada9ad)
• 01: Full - Incremental (b95fb419)
• 00: Full (4d456957)

[vnkozlov]

@JohnTortugo do I understand correctly that we have a loop and the Phi node we are processing is memory input to Allocation?

If I recall correctly, the only way we get to alloc->in(Mem) if there is no Initialize node (there are such cases). In such case Allocation may not have memory out projection.

Why your case see alloc->in(Mem)?

What other Phi node's edge points to?

I am concern if you use projection memory edge of the Allocate you may miss/skip it during search and start searching unrelated path.

[TobiHartmann]

I executed some quick testing and I see failures with

• compiler/gcbarriers/TestArrayCopyWithLargeObjectAlignment.java
• compiler/loopstripmining/TestLoadOnBackedgeWithPrec.java
• compiler/membars/TestMemBarAcquire.java

  668  Phi  === 49 669 670  [[ 667 818 817 816 ]]  #rawptr:BotPTR !jvms: TestLoadOnBackedgeWithPrec::j @ bci:159 (line 55)
  668  Phi  === 49 669 670  [[ 667 818 817 816 ]]  #rawptr:BotPTR !jvms: TestLoadOnBackedgeWithPrec::j @ bci:159 (line 55)
   41  safePoint_poll_tls  === 47 0 819 0 0 42 1421 820 1423 616 0 46 45 44  |1645  [[ 43 39 ]]  !jvms: TestLoadOnBackedgeWithPrec::j @ bci:190 (line 46)
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S9853/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2cd88c15-c79b-46eb-a505-4fbf2c345f82/runs/27421909-81f2-433f-811e-a8e03bb02478/workspace/open/src/hotspot/share/opto/buildOopMap.cpp:365), pid=978899, tid=978928
#  assert(false) failed: there should be an oop in OopMap instead of a live raw oop at safepoint

With -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation on AArch64.

[JohnTortugo]

@vnkozlov - Thank you for letting me know about those edge cases. I'll investigate what happens in those situations.
I created this Gist to demonstrate the problem: https://gist.github.com/JohnTortugo/2e6f183b0bf1e465dc871246b410ef4c

@TobiHartmann - I'll try and reproduce these failures locally.

[vnkozlov]

@vnkozlov - Thank you for letting me know about those edge cases. I'll investigate what happens in those situations.
I created this Gist to demonstrate the problem: https://gist.github.com/JohnTortugo/2e6f183b0bf1e465dc871246b410ef4c

@JohnTortugo - Thank you for demonstration. Now I understand the issue. Yes, your suggestion is reasonable but you need to watch out for missing allocation's memory projection - you should not use nullptr as sentinel. May be add assert and run testing to see if we hit it.

[vnkozlov]

@JohnTortugo are you still working on it? Please, let me know when you are ready for re-review and testing.

[JohnTortugo]

@vnkozlov - yes, I'm still working on it. Unfortunately, I had to push some changes in order to run tests on one of our internal systems..

[JohnTortugo]

Hi @vnkozlov , @TobiHartmann - can you please take a look at the changes and run your internal tests on it? TIA!

@vnkozlov - I added an assert to check that there is a (non_io) memory projection in the Allocate. I ran hotspot-all in a few OS's and the assert didn't trigger. I kept it on the code just in case it may trigger with a different set of JVM options, OS/arch, etc.

[vnkozlov]

Looks good. Few comments for test.
Tobias testing is still running. So far no new failure.

[vnkozlov]

We may need to backport this. See my comments in JDK-8324739.

[vnkozlov]

@JohnTortugo can you look on the attached Test.java from JDK-8324739?
It passed with your initial (v00) fix and failed with latest when you added , /*io_use:*/false

[JohnTortugo]

Thanks for testing Vladimir. I'll take a look into this tomorrow morning PST.

[vnkozlov]

@JohnTortugo, thank you for investigating JDK-8324739.

Let finish this fix then. Please, address my comments about test.
And we need second review/approval for these changes.

[JohnTortugo]

@TobiHartmann - did any test fail in your latest run?

[TobiHartmann]

All tests passed.

[TobiHartmann]

The fix looks reasonable to me.

[openjdk]

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

8322854: Incorrect rematerialization of scalar replaced objects in C2

Reviewed-by: kvn, thartmann

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

• c266800: 8325558: Add jcheck whitespace checking for properties files
• ec20b0a: 8325626: Allow selection of non-matching configurations using CONF=!string
• 618af39: 8325633: Use stricter assertion in callers of Space::is_aligned
• 5dbf137: 8319797: Recursive lightweight locking: Runtime implementation
• 4513da9: 8325470: [AIX] use fclose after fopen in read_psinfo
• 62a4be0: 8325635: Serial: Inline verify_used_region_at_save_marks
• b356fee: 8325458: Rename mlvmJvmtiUtils.h
• 2ed889b: 8323628: Update license on "pass-through" files
• 7c69712: 8325570: Update to Graphviz 9.0.0
• 482c100: 8322865: JavaDoc fails on aggregator modules
• ... and 271 more: https://git.openjdk.org/jdk/compare/5c874c19cb08e5c10204a7ad47fb3075f65633db...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.

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 (@vnkozlov, @TobiHartmann) 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).

[JohnTortugo]

@vnkozlov - all looking good to you?

[vnkozlov]

All look good.

[JohnTortugo]

/integrate

[openjdk]

@JohnTortugo
Your change (at version 27a8196) is now ready to be sponsored by a Committer.

[TobiHartmann]

/sponsor

[openjdk]

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

• 7ec2bad: 8323520: Drop unnecessary virtual specifier in Space
• 71ff2d7: 8325616: JFR ZGC Allocation Stall events should record stack traces
• c3c1cdd: 8325731: Installation instructions for Debian/Ubuntu don't mention autoconf
• f8d8eec: 8325325: Breadcrumb navigation shows preview link for modules and packages
• 088e54f: 8325650: Table of contents scroll timeout not long enough
• c266800: 8325558: Add jcheck whitespace checking for properties files
• ec20b0a: 8325626: Allow selection of non-matching configurations using CONF=!string
• 618af39: 8325633: Use stricter assertion in callers of Space::is_aligned
• 5dbf137: 8319797: Recursive lightweight locking: Runtime implementation
• 4513da9: 8325470: [AIX] use fclose after fopen in read_psinfo
• ... and 276 more: https://git.openjdk.org/jdk/compare/5c874c19cb08e5c10204a7ad47fb3075f65633db...master

Your commit was automatically rebased without conflicts.

[openjdk]

@TobiHartmann @JohnTortugo Pushed as commit 7cd25ed.

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