[lworld] RFR: 8371199: [lworld] Flattening of nullable elements of classes similar to j.l.Long

[Rémi Forax]

On Tue, 4 Nov 2025 19:50:25 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
> 
> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
> 
> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
> 
> Please take a look and leave your reviews, thanks a lot.

Hello,
I do not fully understand why you care about GCs given that the 64bits payload of the value type can not be a pointer or contains a pointer ?
I'm sure i'm missing something :)

Also I suppose that at some point this patch (or a following one) will change the VarHandle implementation (or Unsafe ?), because currently the read/write through a VarHandle will not have the required the memory barriers.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3487903736