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

[Quan Anh Mai]

On Wed, 5 Nov 2025 17:37:58 GMT, Rémi Forax <forax at openjdk.org> wrote:

>> 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.
>> 
> 
> yes, i get that.
> Let me try to rephrase, what your are proposing in optimization that only work if the payload does not contains a pointer.
> The pointer can be a 32bits or a 64 bits pointer, it makes no difference. So i've trouble to understand the code around
> https://github.com/openjdk/valhalla/pull/1720/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aeaR1845
> that behave differently depending on the GC.
> 
>> 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.
> 
> Okay, so i suppose it means that because this considered as non-atomic on the VarHandle side, something like a CAS operation is not supported.

@forax That line is in the `else` branch, i.e. the branch in which we access the payload as a whole. The only change to that part in this PR is to indent it 2 spaces further.

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

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