On Wed, 5 Nov 2025 17:37:58 GMT, Rémi Forax <[email protected]> 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
