[lworld] RFR: 8371199: [lworld] Flattening of nullable elements of classes similar to j.l.Long
Quan Anh Mai
qamai at openjdk.org
Tue Nov 4 19:56:17 UTC 2025
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.
-------------
Commit messages:
- typo
- add support for unnatural nullable atomic layout
Changes: https://git.openjdk.org/valhalla/pull/1720/files
Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1720&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8371199
Stats: 306 lines in 10 files changed: 256 ins; 10 del; 40 mod
Patch: https://git.openjdk.org/valhalla/pull/1720.diff
Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1720/head:pull/1720
PR: https://git.openjdk.org/valhalla/pull/1720
More information about the valhalla-dev
mailing list