On Tue, 4 Nov 2025 20:30:02 GMT, Rémi Forax <[email protected]> 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.

@forax Suppose a value class like this `value record(String name, int idx)`, 
then it should contain a pointer in its payload.

For your second point, `Unsafe::putFlatValue` and `Unsafe::getFlatValue` will 
call into `InlineKlass::write_value_to_addr` and 
`InlineKlass::read_payload_from_addr`, respectively, which are covered by this 
patch. `j.l.i.VarHandleNonAtomicFlatValues`, in turns, calls 
`Unsafe::getFlatValue` for the `get` method and `Unsafe::putFlatValue` for the 
set method. So, I believe they are also fine.

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

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

Reply via email to