[lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v4]

[Tobias Hartmann]

On Tue, 29 Apr 2025 20:12:07 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi
>> 
>> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects.
>> 
>> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE.
>> 
>> An example regarding the issue with tracking the identity of a larval InlineTypeNode:
>> 
>> Consider this pseudobytecode sequence:
>> 
>>     new MyValue;
>>     dup;
>>     loop;
>>     invokespecial MyValue::<init>;
>>     areturn;
>> 
>> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fast path for non intrinsics

Thanks for quickly fixing these issues. I ran another round of testing and there's only one issue left:


compiler/arraycopy/TestEliminatedArrayCopyPhi.java
-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/share/opto/phaseX.cpp:1821), pid=1040062, tid=1040080
#  Error: assert(_worklist.size() == 0) failed
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x17de609]  PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169

Current CompileTask:
C2:455  160    b  4       compiler.arraycopy.TestEliminatedArrayCopyPhi::test (27 bytes)

Stack: [0x00007fadf8385000,0x00007fadf8485000],  sp=0x00007fadf8480270,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x17de609]  PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169  (phaseX.cpp:1821)
V  [libjvm.so+0xb2573a]  Compile::Optimize()+0xa0a  (compile.cpp:2950)
V  [libjvm.so+0xb28b7b]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1feb  (compile.cpp:874)
V  [libjvm.so+0x94e98d]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x46d  (c2compiler.cpp:142)
V  [libjvm.so+0xb37882]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb22  (compileBroker.cpp:2307)
V  [libjvm.so+0xb38888]  CompileBroker::compiler_thread_loop()+0x588  (compileBroker.cpp:1951)
V  [libjvm.so+0x109182f]  JavaThread::thread_main_inner()+0x12f  (javaThread.cpp:773)
V  [libjvm.so+0x1ac19d6]  Thread::call_run()+0xb6  (thread.cpp:231)
V  [libjvm.so+0x1748888]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:877)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2850775468