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

[Damon Fenacci]

> # 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:
> <img width="918" alt="image" src="https://github.com/openjdk/jdk/assets/2198987/40796037-1259-41a3-8429-3ced1fdf96c9">
> 
> 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"...
> https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/hotspot/share/opto/callnode.hpp#L509-L511
> 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*...

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/opto/callnode.hpp
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17500/files
  - new: https://git.openjdk.org/jdk/pull/17500/files/c5f693eb..c6caf715

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17500&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17500&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17500/head:pull/17500

PR: https://git.openjdk.org/jdk/pull/17500