I really like this, it's far better than how i was seeing Valhalla,
pushing .ref into a corner is a good move.
Yes, we always disliked how prevalent .ref was; it took several rounds
of "shaking the box" to get it to stay in the corner.
I still hope that moving from B1 to B2 can be almost backward
compatible, if no direct access to the constructor, no synchronized
and reasonable uses of ==.
Yes, this works out better than we had hoped it might; as you say, if B1
is value-based, it should be an "almost compatible" move to convert to
B2. Amazingly, it might even be "almost compatible" to go in the other
direction too, something we'd almost given up on the possibility of.
Codes like a class, indeed.
The cost of this is, of course, that a B2 class gets less optimization
than a B3 one (though more than a B1 one.) Less heap flattening, more
footprint, more null checks. Though still substantial stack (calling
convention) / IR (scalarization) flattening. How we guide people to
this is the next challenge.
My only concern now is the dual of Kevin's concern,
what if people discover that they always want to use the
identitiy-free reference types (B2), because it is better integrated
with the rest of the Java world and that in the end, the OG/pure
primitive types (B3) are almost never used.
In other words: having solved the almost-impossible technical problems,
we now face the harder pedagogical problem :)
I'm actually worried about the opposite, though! I think its a bigger
risk that people will use B3 over B2 "because performance", and put
themselves in danger (e.g., tearing, unexpected zeroes) without
realizing it.
