On Wed, 21 Jan 2026 10:29:00 GMT, Joel Sikström <[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 > > 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
