On Mon, 9 Feb 2026 14:07:45 GMT, Axel Boldt-Christmas <[email protected]> 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
