[lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize" cannot work well [v2]
Xiaohong Gong
xgong at openjdk.org
Fri Aug 18 07:54:56 UTC 2023
On Thu, 17 Aug 2023 10:04:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Not flatten L-descriptor value object field even it is final
>
> Thanks for investigating this issue. I've run some quick testing and there are new failures:
>
> `compiler/valhalla/inlinetypes/TestC1.java` with `-XX:TieredStopAtLevel=1`:
>
>
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/workspace/open/src/hotspot/share/c1/c1_LIRGenerator.cpp:1778), pid=336001, tid=336015
> # assert(field->type()->as_inline_klass()->is_initialized()) failed: Must be
> #
> # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, compiled mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V [libjvm.so+0x7dc168] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808
>
> Current CompileTask:
> C1: 7349 3404 b 1 compiler.valhalla.inlinetypes.TestC1::test7_verifier (47 bytes)
>
> Stack: [0x00007f16d9b00000,0x00007f16d9c00000], sp=0x00007f16d9bfd810, free space=1014k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x7dc168] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808 (c1_LIRGenerator.cpp:1778)
> V [libjvm.so+0x7de2ee] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x52e (c1_LIRGenerator.cpp:2365)
> V [libjvm.so+0x7c2433] LIRGenerator::do_root(Instruction*)+0x63 (c1_LIRGenerator.cpp:378)
> V [libjvm.so+0x7c799e] non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x5e (c1_LIRGenerator.cpp:375)
> V [libjvm.so+0x78a891] BlockList::iterate_forward(BlockClosure*)+0x41 (c1_Instruction.cpp:1026)
> V [libjvm.so+0x74a94e] Compilation::emit_lir()+0x50e (c1_Compilation.cpp:258)
> V [libjvm.so+0x74d30f] Compilation::compile_java_method()+0x32f (c1_Compilation.cpp:404)
> V [libjvm.so+0x74dc29] Compilation::compile_method()+0x179 (c1_Compilation.cpp:473)
> V [libjvm.so+0x74e41a] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x35a (c1_Compilation.cpp:606)
> V [libjvm.so+0x74ff2e] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde (c1_Compiler.cpp:254)
> V [libjvm.so+0xa37780] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00 (compileBroker.cpp:2265)
> V [libjvm.so+0xa385a8] CompileBroker::compiler_thread_loop()+0x5b8 (compileBroker.cpp:1944)
> V [li...
Thanks for looking at this PR @TobiHartmann ! I think there maybe some potential issues exposed after this change, since almost all value objects cannot be flattened anymore with `-XX:InlineFieldMaxFlatSize=0`, which may need the buffer allocated.
> Thanks for investigating this issue. I've run some quick testing and there are new failures:
>
> `compiler/valhalla/inlinetypes/TestC1.java` with `-XX:TieredStopAtLevel=1`:
>
> ```
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/workspace/open/src/hotspot/share/c1/c1_LIRGenerator.cpp:1778), pid=336001, tid=336015
> # assert(field->type()->as_inline_klass()->is_initialized()) failed: Must be
> #
> # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, compiled mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V [libjvm.so+0x7dc168] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808
>
> Current CompileTask:
> C1: 7349 3404 b 1 compiler.valhalla.inlinetypes.TestC1::test7_verifier (47 bytes)
>
> Stack: [0x00007f16d9b00000,0x00007f16d9c00000], sp=0x00007f16d9bfd810, free space=1014k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x7dc168] LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808 (c1_LIRGenerator.cpp:1778)
> V [libjvm.so+0x7de2ee] LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x52e (c1_LIRGenerator.cpp:2365)
> V [libjvm.so+0x7c2433] LIRGenerator::do_root(Instruction*)+0x63 (c1_LIRGenerator.cpp:378)
> V [libjvm.so+0x7c799e] non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x5e (c1_LIRGenerator.cpp:375)
> V [libjvm.so+0x78a891] BlockList::iterate_forward(BlockClosure*)+0x41 (c1_Instruction.cpp:1026)
> V [libjvm.so+0x74a94e] Compilation::emit_lir()+0x50e (c1_Compilation.cpp:258)
> V [libjvm.so+0x74d30f] Compilation::compile_java_method()+0x32f (c1_Compilation.cpp:404)
> V [libjvm.so+0x74dc29] Compilation::compile_method()+0x179 (c1_Compilation.cpp:473)
> V [libjvm.so+0x74e41a] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x35a (c1_Compilation.cpp:606)
> V [libjvm.so+0x74ff2e] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde (c1_Compiler.cpp:254)
> V [libjvm.so+0xa37780] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00 (compileBroker.cpp:2265)
> V [libjvm.so+0xa385a8] CompileBroker::compiler_thread_loop()+0x5b8 (compileBroker.cpp:1944)
> V [libjvm.so+0xef4fec] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:720)
> V [libjvm.so+0x17f23ca] Thread::call_run()+0xba (thread.cpp:217)
> V [libjvm.so+0x14dbdcc] thread_native_entry(Thread*)+0x11c (os_linux.cpp:779)
> ```
Could you please show more env/options information on this issue? I cannot reproduce it even with `-XX:InlineFieldMaxFlatSize=0 -XX:TieredStopAtLevel=1` on our internal Arm NEON machine. Since this PR will change the flat state of value objects, I'm not sure whether there is some affects on the value class loading/initialization policy?
> `compiler/valhalla/inlinetypes/TestBasicFunctionality.java` with `-DWarmup=0 -DVerifyIR=false`
>
> ```
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/workspace/open/src/hotspot/share/opto/inlinetypenode.cpp:884), pid=3588916, tid=3588932> # assert(!null_free || vt->is_allocated(&gvn)) failed: inline type should be allocated
> #
> # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V [libjvm.so+0xe57aa7] InlineTypeNode::make_from_oop_impl(GraphKit*, Node*, ciInlineKlass*, bool, GrowableArray<ciType*>&)+0x417
>
> Current CompileTask:
> C2: 40242 965 b 4 compiler.valhalla.inlinetypes.TestBasicFunctionality::test37 (2 bytes)
>
> Stack: [0x00007f0d778ff000,0x00007f0d779ff000], sp=0x00007f0d779fb8e0, free space=1010k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xe57aa7] InlineTypeNode::make_from_oop_impl(GraphKit*, Node*, ciInlineKlass*, bool, GrowableArray<ciType*>&)+0x417 (inlinetypenode.cpp:884)
> V [libjvm.so+0xe58e54] InlineTypeNode::initialize_fields(GraphKit*, MultiNode*, unsigned int&, bool, bool, Node*, GrowableArray<ciType*>&)+0xa24 (inlinetypenode.cpp:1146)
> V [libjvm.so+0xe59603] InlineTypeNode::make_from_multi(GraphKit*, MultiNode*, ciInlineKlass*, unsigned int&, bool, bool)+0x103 (inlinetypenode.cpp:920)
> V [libjvm.so+0x15227ee] Compile::build_start_state(StartNode*, TypeFunc const*)+0x7ee (parse1.cpp:878)
> V [libjvm.so+0xa2b956] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1706 (compile.cpp:792)
> V [libjvm.so+0x876b4e] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x10e (c2compiler.cpp:115)
> V [libjvm.so+0xa37780] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00 (compileBroker.cpp:2265)
> V [libjvm.so+0xa385a8] CompileBroker::compiler_thread_loop()+0x5b8 (compileBroker.cpp:1944)
> V [libjvm.so+0xef4fec] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:720)
> V [libjvm.so+0x17f23ca] Thread::call_run()+0xba (thread.cpp:217)
> V [libjvm.so+0x14dbdcc] thread_native_entry(Thread*)+0x11c (os_linux.cpp:779)
> ```
I also met the same crash on `lworld+vector` branch with this change when I was running Vector API tests. Actually I don't quite understand what this assertion mean? Why the `null_free` value type must be allocated in this routine? I need more investigation on it. And it will be helpful if anyone could give some guide/advice on this part. Thanks in advance!
Best Regards,
Xiaohong
-------------
PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1683510063
More information about the valhalla-dev
mailing list