[lworld] RFR: 8331006: [lworld] Support of null markers for nullable flat fields [v2]

[Dan Heidinga]

On Wed, 1 May 2024 13:50:39 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/interpreter/interpreterRuntime.cpp line 355:
>> 
>>> 353:   int nm_offset = ik->null_marker_offsets_array()->at(entry->field_index());
>>> 354:   if (val_h() == nullptr) {
>>> 355:     obj_h()->byte_field_put(nm_offset, (jbyte)0);
>> 
>> Do we need a barrier here?  When we write the null marker, it is as if we wrote the null marker and then nulled the fields out (which we don't actually do) which makes me think we always need the barrier after writing the null marker to be consistent with the non-null case.
>
> In this case, there is a single write from the current thread, so there's no visibility ordering issue like with the non-null case. A concurrently reading thread will check (or has already read) the null marker, and this would be no different than reading a reference field being set to null. So I don't think we need a barrier here, but if you really think there's a potential issue, I can add one.

I think you're right here and we don't need the `release_byte_field_put` here.  Just as we're happy for reads/writes of null references to slowly make their way to other threads, a slow discovery of the null bit is fine given the other value fields are stable before the bit flips.

The barrier you have in place is sufficient for that constraint.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1586410470