[lworld] RFR: 8371199: [lworld] Flattening of nullable elements of classes similar to j.l.Long
Tobias Hartmann
thartmann at openjdk.org
Fri Nov 7 10:51:32 UTC 2025
On Wed, 5 Nov 2025 07:31:06 GMT, Hannes Greule <hgreule at openjdk.org> wrote:
>> @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.
>
>> Suppose a value class like this `value record(String name, int idx)`, then it should contain a pointer in its payload.
>
> I don't know how this is currently implemented in the GC, but wouldn't it make sense for the GC to check whether the value is marked as null first, and ignore the rest of the value in that case?
>
> Especially for ZGC flattening currently doesn't happen even for `value record(String name)` from my understanding (and more generally, with compressed oops disabled?), this might be beneficial. I don't know how this interacts with GC barriers, there is most likely more to it than I know of :)
>
> That said, restricting to payloads without oops makes this change easier to reason about, so - assuming it makes sense - extending to payloads with oops as a follow-up might be better.
@SirYwell @forax I think there's some confusion around the GC related code here. First of all, this is not specific to @merykitty's changes. This is **not** new, he just moved existing code.
That particular code is needed to support 64-bit flat accesses with one or two 32-bit compressed oops. Currently, two oops are only possible if the field/array is null-free. Different GCs need different barriers, so we need to emit different code depending on which GC is used.
-------------
PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3501840147
More information about the valhalla-dev
mailing list