[lworld] RFR: 8331006: [lworld] Support of null markers for nullable flat fields [v2]
Frederic Parain
fparain at openjdk.org
Wed May 1 13:53:05 UTC 2024
On Tue, 30 Apr 2024 14:08:33 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:
>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fixing issues spotted during reviews
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1586320878
More information about the valhalla-dev
mailing list