On Wed, 21 Jan 2026 08:47:25 GMT, Paul Hübner <[email protected]> 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
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 263:
>
>> 261: pop(obj);
>> 262: bind(slow_path);
>> 263: call_VM(obj, CAST_FROM_FN_PTR(address,
>> InterpreterRuntime::read_flat_field),
>
> In your writeup you mention `call_VM_leaf` is called, but I only see
> references to `call_VM` in the code yet the comments say `call_VM_leaf`. Do
> we/did we `call_VM_leaf` at any point?
The call to `call_VM_leaf` is in the copy-path:
MacroAssembler::flat_field_copy
BarrierSetAssembler::flat_field_copy
call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetRuntime::value_copy), ...)
-------------
PR Review Comment:
https://git.openjdk.org/valhalla/pull/1936#discussion_r2711662366
