> 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: dead code ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1720/files - new: https://git.openjdk.org/valhalla/pull/1720/files/542c2fd8..e80107b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1720&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1720&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 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
