JDK-8317299: safepoint scalarization doesn't keep track of the depth of the JVM state

[dafedafe]

Issue

The origin of the problem is tied to the fact that, when C2 optimizes vector boxes, it performs safepoint object scalarization before late inlining.
This can lead to situations in which scalarization adds scalarized values to the JVM state and late inlining of further methods adds further JVM state entries on top for each inlined method.
With the example of the reported bug (TestIntrinsicBailOut.java) we get to a situation like this:

...
bc: JVMS depth=6 loc=20 stk=23 arg=23 mon=23 scalar=23 end=23 mondepth=0 sp=0 bci=1 reexecute=false method=virtual jobject jdk.incubator.vector.ByteVector.rearrangeTemplate(jobject, jobject)
bc: JVMS depth=7 loc=23 stk=27 arg=27 mon=27 scalar=27 end=27 mondepth=0 sp=0 bci=36 reexecute=false method=virtual jobject jdk.incubator.vector.AbstractShuffle.checkIndexes()
bc: JVMS depth=8 loc=27 stk=28 arg=28 mon=28 scalar=28 end=28 mondepth=0 sp=0 bci=1 reexecute=false method=virtual jobject jdk.incubator.vector.AbstractShuffle.reorder()
bc: JVMS depth=9 loc=28 stk=29 arg=29 mon=29 scalar=29 end=31 mondepth=0 sp=0 bci=1 reexecute=false method=virtual jobject jdk.internal.vm.vector.VectorSupport$VectorPayload.getPayload()
bc: JVMS depth=10 loc=31 stk=32 arg=32 mon=32 scalar=32 end=32 mondepth=0 sp=0 bci=3 reexecute=false method=static jobject jdk.internal.vm.vector.VectorSupport.maybeRebox(jobject)
bc: JVMS depth=11 loc=32 stk=33 arg=33 mon=33 scalar=33 end=33 mondepth=0 sp=0 bci=1 reexecute=false method=virtual void jdk.internal.misc.Unsafe.loadFence()

JVMS depth=9 shows 2 scalars but 2 further inlines added 2 more JVM states (with no scalars).

The corresponding node looks like this:

To keep track of its scalarized inputs, SafePointScalarObjectNode keeps a field _first_index, which is supposed to be "relative to the last (youngest) jvms->_scloff"...

jdk/src/hotspot/share/opto/callnode.hpp

Lines 509 to 511 in c5e7245

	uint _first_index; // First input edge relative index of a SafePoint node where
	// states of the scalarized object fields are collected.
	// It is relative to the last (youngest) jvms->_scloff.

but if there are late inlined methods, this field is going to be relative to the JVM state at the depth before inlining happened (e.g. depth=9 in the example) and not relative to the youngest depth.

Solution

In order to keep track of the right depth a _depth field is added to SafePointScalarObjectNode, which refers to the depth of the JVM state the _first_index field refers to. The method uint first_index(JVMState* jvms) is adapted accordingly.

---

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-8317299: safepoint scalarization doesn't keep track of the depth of the JVM state (Bug - P3)

Reviewers

• Tobias Hartmann (@TobiHartmann - Reviewer) ⚠️ Review applies to c5f693eb
• Vladimir Ivanov (@iwanowww - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 17500

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

• 01: Full - Incremental (c6caf715)
• 00: Full (c5f693eb)

[TobiHartmann]

Great work, Damon. When we discussed this, I always wondered why we don't hit the same issue in Valhalla, where we perform even more aggressive scalarization during IGVN. Turns out that I postponed scalarization to after inlining, to work around that exact problem:
https://github.com/openjdk/valhalla/blob/c48006dfc05bb0c41ab9ae55ead226356259c46d/src/hotspot/share/opto/compile.cpp#L2002

With your fix, we can remove that limitation. I filed JDK-8324605 for this.

[vnkozlov]

Interesting. Could it resolve the issue JDK-8276112 so we can REDO DK-8276998?

[TobiHartmann]

Good catch, Vladimir. I completely forgot about JDK-8276112 but from re-reading my old analysis in #6333, it's most likely the exact same issue.

[TobiHartmann]

The fix looks good to me.

[openjdk]

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

8317299: safepoint scalarization doesn't keep track of the depth of the JVM state

Reviewed-by: thartmann, vlivanov

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

• 6697160: 8320712: Rewrite BadFactoryTest in pure Java
• 725314f: 8324771: Obsolete RAMFraction related flags
• ec6c35c: 8324970: Serial: Refactor signature of maintain_old_to_young_invariant
• b5c267f: 8324632: Update Zlib Data Compression Library to Version 1.3.1
• ec56c72: 8323601: Improve LayoutPath.PathElement::toString
• f7121de: 8322648: Improve class initialization barrier in TemplateTable::_new for PPC
• 577de17: 8259550: The content of the print out displayed incomplete with the NimbusLAF
• 83b3c9b: 8322649: Improve class initialization barrier in TemplateTable::_new for S390
• 7d1a488: 8324861: Exceptions::wrap_dynamic_exception() doesn't have ResourceMark
• c3c1d5b: 8324998: Add test cases for String.regionMatches comparing Turkic dotted/dotless I with uppercase latin I
• ... and 125 more: https://git.openjdk.org/jdk/compare/aeb304b29eaaba2b7a8fef85ee46cbfca27dbfbe...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.

[iwanowww]

Looks good.

[dafedafe]

Interesting. Could it resolve the issue JDK-8276112 so we can REDO DK-8276998?

Thanks for pointing this out @vnkozlov. I've tried reapplying JDK-8261137 to reproduce the JDK-8276998 issue before applying this change but couldn't reproduce it anymore. I'll mention this issue in the REDO anyway.

[dafedafe]

@TobiHartmann @iwanowww thanks a lot for reviewing!

[dafedafe]

/integrate

[openjdk]

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

• 542b0b6: 8324126: Error message for mistyping -XX:+Unlock...Options is not helpful
• 9ee9f28: 8325213: Flags introduced by configure script are not passed to ADLC build
• 729ae1d: 8325266: Enable this-escape javac warning in jdk.javadoc
• e0fd3f4: 8325081: Move '_soft_ref_policy' to 'CollectedHeap'
• f1f9398: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern
• ab3b941: 8325270: ProblemList two compiler/intrinsics/float16 tests that fail due to JDK-8324724
• f31957e: 8317636: Improve heap walking API tests to verify correctness of field indexes
• fd3042a: 8318566: Heap walking functions should not use FilteredFieldStream
• 209d87a: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value
• 7777eb5: 8321931: memory_swap_current_in_bytes reports 0 as "unlimited"
• ... and 188 more: https://git.openjdk.org/jdk/compare/aeb304b29eaaba2b7a8fef85ee46cbfca27dbfbe...master

Your commit was automatically rebased without conflicts.

[openjdk]

@dafedafe Pushed as commit 6d911f6.

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

[TobiHartmann]

/backport jdk22u

[openjdk]

@TobiHartmann the backport was successfully created on the branch backport-TobiHartmann-6d911f68 in my personal fork of openjdk/jdk22u. To create a pull request with this backport targeting openjdk/jdk22u:master, 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 6d911f68 from the openjdk/jdk repository.

The commit being backported was authored by Damon Fenacci on 6 Feb 2024 and was reviewed by Tobias Hartmann and Vladimir Ivanov.

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/jdk22u:

$ git fetch https://github.com/openjdk-bots/jdk22u.git backport-TobiHartmann-6d911f68:backport-TobiHartmann-6d911f68
$ git checkout backport-TobiHartmann-6d911f68
# make changes
$ git add paths/to/changed/files
$ git commit --message 'Describe additional changes made'
$ git push https://github.com/openjdk-bots/jdk22u.git backport-TobiHartmann-6d911f68