User model stacking: current status
Brian Goetz
brian.goetz at oracle.com
Mon May 9 15:51:53 UTC 2022
>
> So where this brings us is back to something that might feel like
> the four-bucket approach in the third bullet above, but with two
> big differences: atomicity is an explicit property of a class,
> rather than a property of reference-ness, and a B3.ref is not
> necessarily the same as a B2.
>
>
> I don't follow how a B3.ref != a B2, unless you just mean that you can
> have a reference to a bogus instance more easily than B2 can (which
> takes serialization/reflection to do that).
It means that a B3.ref is exactly as subject to tearing as the
same-atomicity B3, whereas a B2 is not.
> - B3 classes can further be marked non-atomic; this unlocks
> greater flattening in the heap at the cost of tearing under race,
> and is suitable for classes without cross-field invariants.
> Non-atomicity accrues equally to B3.ref and B3.val; a non-atomic
> B3.ref still tears (and therefore might expose its zero under
> race, as per friday's discussions.)
>
>
> Am I right that this "non-atomic" marker would be ignored for classes
> like Integer where the vm can tell that it can just give you the best
> of both worlds?
We can provide atomicity semantics for sufficiently small objects at no
cost. In practicality this probably means "classes whose layout boils
down to a single 32-bit-or-smaller primitive, or a single reference".
>
> But seriously, we won't get away with pretending there are just 3
> buckets if we do this. Let's be honest and call it B4.
"Bucket" is a term that makes sense in language design, but need not
flow into the user model. But yes, there really are three things that
the user needs control over: identity, zero-friendliness, atomicity. If
you want to call that four buckets, I won't argue. The real discussion
here is whether these controls need to be *separate*. And I think they do:
- The premise of Valhalla is that the VM can't guess whether identity
is needed, so the user has to explicitly disavow it to enable more goodies;
- Classes like LocalDate have no good zero, so the user needs to be
able to disavow the zero value when it doesn't fit the semantics of the
class;
- (the controversial one) Atomicity is simply too confusing and
potentially astonishing to piggyback on "primitive-ness" or
"reference-ness" in a codes-like-a-class world.
> Would I be right that we can achieve primitive unification even
> without B4? There is nothing wrong with our delivering many
> performance gains while leaving others on the table for later.
Yes, delivering primitive unification first means you can't have flat
Complex yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220509/a1bc6770/attachment-0001.htm>
More information about the valhalla-spec-experts
mailing list