On Wed, 5 Nov 2025 07:31:06 GMT, Hannes Greule <[email protected]> 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
