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. > 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. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3492527038
