[lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize" cannot work well [v2]

Thu Aug 17 10:07:49 UTC 2023

On Tue, 25 Jul 2023 09:56:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently all the non-static final fields with inline type can be flattened, even if the layout size of the inline type is beyond
>> the max flat size specified by `InlineFieldMaxFlatSize`. Please refer to the condition check [1] which decides whether a field
>> can be flattened or not.
>> 
>> Field flattening has two major side effects: atomicity and size. Fields with atomic access limitation or large size that exceeds
>> the specified threshold value cannot be flattened. And final fields are special that they are immutable after initialized. So the atomic check for them can be ignored. Hence, 1) for the atomicity free type like the primitive class, the final and non-final fields with such type can be flattened. And 2) for the normal value class that has atomic feature, only the final fields with such type can be flattened. And all kinds of the flattened fields should not exceed the specified max flat size. Please see more details from [1] [2].
>> 
>> The original condition [1] matches the atomicity check but not the flat size limitation. Promoting the flat size check before all other checks matches the flattening policy and can make the VM option `InlineFieldMaxFlatSize` work for final fields as well.
>> 
>> This patch also fixed the jtreg crashes involved after the field flattening condition is changed. Those tests fail with setting
>> `-XX:+InlineFieldMaxFlatSize=0` by default. The main issue is the non-flattened inline type field is not buffered which is expected to be. The root cause is when parsing `withfield`, the compiler checks whether the field is primitive class type while not its flattening status. Changing to check the flattening status instead can fix the crash.
>> 
>> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L759
>> [2] https://mail.openjdk.org/pipermail/valhalla-dev/2023-June/011262.html
>> [3] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011265.html
>
> 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  [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)

`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)

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1682003716