[lworld] RFR: 8335256: [lworld] compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently [v2]
Tobias Hartmann
thartmann at openjdk.org
Tue Apr 29 08:39:13 UTC 2025
On Mon, 28 Apr 2025 14:30:48 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>
> - Merge branch 'lworld' into larvaloop
> - remove larval InlineTypeNode
Great work @merykitty! Thanks a lot for the investigation. When working on the new value object construction model, I was concerned that we might end up with adding identity back to the larvals but I was still naively hoping that we could get around that. Looks like we can't. Maybe you could change the title to something more descriptive for future reference / search.
I run this through testing and there are a few issues:
applications/ctw/modules/jdk_internal_le.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/macro.cpp:2970), pid=1140043, tid=1140412
# assert(!n->as_AbstractLock()->is_eliminated()) failed: sanity
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x15359a4] PhaseMacroExpand::eliminate_macro_nodes()+0x714
Current CompileTask:
C2:26441 3356 !b jdk.internal.org.jline.utils.NonBlockingInputStreamImpl::run (312 bytes)
Stack: [0x00007f27dbbfd000,0x00007f27dbcfd000], sp=0x00007f27dbcf8250, free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x15359a4] PhaseMacroExpand::eliminate_macro_nodes()+0x714 (macro.cpp:2970)
V [libjvm.so+0xb26617] Compile::Optimize()+0x1867 (compile.cpp:2903)
V [libjvm.so+0xb28ceb] 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+0xb379f2] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb22 (compileBroker.cpp:2307)
V [libjvm.so+0xb389f8] CompileBroker::compiler_thread_loop()+0x588 (compileBroker.cpp:1951)
V [libjvm.so+0x109191f] JavaThread::thread_main_inner()+0x12f (javaThread.cpp:773)
V [libjvm.so+0x1abf606] Thread::call_run()+0xb6 (thread.cpp:231)
V [libjvm.so+0x17466d8] thread_native_entry(Thread*)+0x128 (os_linux.cpp:877)
compiler/valhalla/inlinetypes/TestValueClasses.java
-DWarmup=0 -DVerifyIR=false
OR
-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true
Caused by: java.lang.RuntimeException: assertEquals expected: compiler.valhalla.inlinetypes.TestValueClasses$SmallNullable1 at b0186fd4 but was: compiler.valhalla.inlinetypes.TestValueClasses$SmallNullable1 at 6279ef0a
at jdk.test.lib.Asserts.fail(Asserts.java:715)
at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
at compiler.valhalla.inlinetypes.TestValueClasses.test9_verifier(TestValueClasses.java:434)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
... 7 more
compiler/valhalla/inlinetypes/TestValueConstruction.java
-XX:+UnlockDiagnosticVMOptions -XX:+AbortVMOnCompilationFailure
This is expected but to be able to run this test with `-XX:+AbortVMOnCompilationFailure`, which is valuable, maybe we should put your new test in another jtreg test and hardcode `-XX:-AbortVMOnCompilationFailure` there?
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (workspace/open/src/hotspot/share/compiler/compileBroker.cpp:2114), pid=2843210, tid=2843229
# fatal error: Not compilable at tier 4: OSR starts with non-empty stack
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-28-0856180.tobias.hartmann.valhalla2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xb30beb] CompileBroker::handle_compile_error(CompilerThread*, CompileTask*, ciEnv*, int, char const*)+0x6b
Current CompileTask:
C2:6345 1087 % b 4 compiler.valhalla.inlinetypes.TestValueConstruction$Code_0::multipleOccurrencesInJVMSReturnStack @ 5 (22 bytes)
Stack: [0x00007fc85457f000,0x00007fc85467f000], sp=0x00007fc85467d450, free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xb30beb] CompileBroker::handle_compile_error(CompilerThread*, CompileTask*, ciEnv*, int, char const*)+0x6b (compileBroker.cpp:2114)
V [libjvm.so+0xb3734c] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x47c (compileBroker.cpp:2340)
V [libjvm.so+0xb389f8] CompileBroker::compiler_thread_loop()+0x588 (compileBroker.cpp:1951)
V [libjvm.so+0x109191f] JavaThread::thread_main_inner()+0x12f (javaThread.cpp:773)
V [libjvm.so+0x1abf606] Thread::call_run()+0xb6 (thread.cpp:231)
V [libjvm.so+0x17466d8] thread_native_entry(Thread*)+0x128 (os_linux.cpp:877)
compiler/valhalla/inlinetypes/TestValueConstruction.java
Various flags:
- No flags
- "-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressArrayCopyMacroNode -XX:+StressCallingConvention -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN -XX:+StressReflectiveCode -XX:+StressMethodHandleLinkerInlining -XX:+StressCompiledExceptionHandlers -XX:MaxNodeLimit=100000"
java.lang.RuntimeException: assertEquals expected: x: 0 but was: x: 50000
at jdk.test.lib.Asserts.fail(Asserts.java:715)
at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
at compiler.valhalla.inlinetypes.TestValueConstruction.check(TestValueConstruction.java:1851)
at compiler.valhalla.inlinetypes.TestValueConstruction.run(TestValueConstruction.java:1846)
at compiler.valhalla.inlinetypes.TestValueConstruction.main(TestValueConstruction.java:1773)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1447)
-------------
PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2837948418
More information about the valhalla-dev
mailing list