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.

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 Valhalla to their platforms 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.