> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Dan Heidinga" <heidi...@redhat.com> > Cc: "Kevin Bourrillion" <kev...@google.com>, "valhalla-spec-experts" > <valhalla-spec-experts@openjdk.java.net> > Sent: Monday, April 25, 2022 4:59:14 PM > Subject: Re: Objects vs. values, the continuation
>>> The fact that these are "small" (at most 64 bits) is incidental, not >>> essential; >>> introducing a new quadruple type would not destabilize our concept of a >>> primitive value. >> If we can tip the user's mental model so that they believe "small is >> good" for B3 values, then we aid them in hitting the sweet space of >> the design and help them avoid tearing issues. It doesn't change the >> model but the more we can encourage the belief that B3 values should >> be <= 64it the happier users will be with the results. > I think its reasonable to say that “we can flatten 64 bits better than we can > flatten 256, but go ahead and write the code you want, and we’ll do what we > can.” Recent data suggests that we can get to 128 more quickly than we had > initially expected, and (especially if we can drop the null footprint tax, as > B3 does), you can do a lot in 128. Presumably in some future hardware > generation this number will go up again, whether that is 5 or 10 years from > now, we don’t know right now. This is tangential but i write it here because i will forget again. There is an issue with representing B2 as a 128 bits value, while Intel and ARM both provides 128 atomic read/write if vectorized registers are used, they do not provide a CAS (or the equivament on ARM) on 128 bits. This is an issue for VarHandle because - one can create a VarHandle on any field (array cell), it does not have to be volatile (there is no way to declare the content of an array volatile) - VarHandle.compareAndSet() has to work. If we keep the exact same semantics for VarHandle, we can not use 128 bits for fields declared as B2 because a VarHandle may be constructed on it later. Rémi
