[lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v2]

[Frederic Parain]

On Wed, 21 Jan 2026 10:29:00 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example).
>> 
>> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails.
>> 
>> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus.
>> 
>> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway.
>> 
>> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug
>
> Joel Sikström has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dont handle:ize obj in InterpreterRuntime::read_flat_field

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1171:

> 1169: 
> 1170:   movptr(tmp1, Address(entry, ResolvedFieldEntry::field_holder_offset()));
> 1171:   get_inline_type_field_klass(tmp1, tmp2, field_klass);

This was the last place where get_inline_type_field_klass() was used, so this method can be removed from the MacroAssembler class.
Note that get_inline_type_field_klass() was not used in the aarch64 implementation of read_flat_field(), but the get_inline_type_field_klass()  method still exists in the aarch64 MacroAssembler. This dead code could be removed too.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2713809965