On Wed, 5 Nov 2025 04:25:55 GMT, Quan Anh Mai <[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. > > Quan Anh Mai has updated the pull request incrementally with one additional > commit since the last revision: > > missing barrier >Ended up concluding that it was a dead end—I'd suggest discussing on >[[email protected]](mailto:[email protected]) if you'd like to >understand what the concerns were. FTR, @forax provided an example here: https://mail.openjdk.org/pipermail/valhalla-dev/2025-November/016074.html ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3501798087
