[lworld] RFR: 8377451: [lworld] Add ValuePayload abstraction [v3]

[Frederic Parain]

On Mon, 9 Feb 2026 14:07:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Probably good to double check. I do not think we assume the invariant that this is not a concurrently accessed object.
>> 
>> My assumption is that `BufferedValuePayload` have an immutable payload, only the null marker may be indeterminate. A buffered payload cannot be transformed from a valid object -> null.
>> 
>> With the removal of the private buffer, (which now instead uses a FlatArray of length 1) we should not have mutable buffered objects out in Java. Only mutable flat fields and flat array elements. But they do not have the immutability assumption.
>
> And I am not convinced that we have the correct synch primitives everywhere for the immutable invariant to hold. But I think that the the immutable invariant is the intended design. 
> 
> If it was not and we are allowed to observe the pre-copy / pre-construction contents of a buffered object I think both this and the previous implementation is broken w.r.t. concurrent reads.

The 'src' is a buffered value. If the value has a null-marker, it is not guaranteed that the payload is marked as non-null, for instance, if this is a buffered value copied from a null-free flat value. When the buffered value is copied back to be flattened in a container, the null-marker is set to non-null before the copy. The current runtime code do it unconditionally, but it only matters if the destination is a nullable flat value.

The main reason to update the null-marker in a buffered value is to be able to perform atomic updates of nullable-flat value. Because the null-marker and the value content must be updated atomically, the VM must prepare the "bundle" (value's fields + null-marker) to copy before using the atomic copy instruction.

There's no synchronization in the null-marker update because this is an uni-directional change: always from (potentially) marked-as-null to marked-as-not-null. All threads would write the same value to the null-marker, they would all see their own update of the null-marker when doing the copying in the next step.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2068#discussion_r2788319261