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

[Frederic Parain]

On Tue, 30 Apr 2024 14:14:39 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> src/hotspot/share/interpreter/interpreterRuntime.cpp line 362:
>> 
>>> 360:     // The interpreter copies values with a bulk operation
>>> 361:     // To avoid accidently setting the null marker to "null" during
>>> 362:     // the copying, the null marker is set to non zero in the source object
>> 
>> Is this saying if the null marker is embedded in the value field layout rather than placed separately, we set it to non-null before writing it into the container?  This tripped me up a little bit reading the code but I think it makes sense
>
> How does that work for our memory barriers then?  Do we not need a release here as well given the acquire used to read the null marker?

This particular case cannot currently happen with JEP 401 model implementation (nullable flat field are limited to single field values until we have atomic updates supported). But it involves the tearing issue the interpreter has in some cases. So, even adding a barrier would not make the code correct. I'd prefer to address the issue of this particular code when fixing the wider interpreter tearing issue.

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

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