> On Apr 27, 2022, at 7:36 PM, Kevin Bourrillion <kev...@google.com> wrote: > > This is kinda reading as... > > * First we have 3 buckets > * But people ask if there could be just 2 buckets > * No, so let's have 5 buckets. > > I don't understand why this is happening, but I take it back! I take back > what I said about 2 buckets!
Just so we don't lose this history, a reminder that back when we settled on the 3 buckets, we viewed it as a useful simplification from a more general approach with lots of "knobs". Instead of asking developers to think about 3-4 mostly-orthogonal properties and set them all appropriately, we preferred a model in which *objects* and *primitive values* were distinct entities with distinct properties. Atomicity, nullability, etc., weren't extra things to have to reason about independently, they were natural consequences of what it meant to be (or not) a variable that stores objects. That was awhile ago, we may have learned some things since then, but I think there's still something to the idea that we can expect everybody to understand the difference between objects and primitives, even if they don't totally understand all the implications. (When they eventually discover some corner of the implications, we hope they'll say, "oh, sure, that makes sense because this is/isn't an object.") > On Apr 28, 2022, at 8:13 AM, Brian Goetz <brian.go...@oracle.com> wrote: > > My conclusion is that problem here is that we’re piggybacking atomicity on > other things, in non-obvious ways. The author of the class knows when > atomicity is needed to protect invariants (specifically, cross-field > invariants), and when it is not, so let that simply be selected at the > declaration site. Opting out of atomicity is safer and less surprising, so > that argues for tagging classes that don’t need atomicity as `non-atomic`. > (For some classes, such as single-field classes, it makes no difference, > because preserving atomicity has no cost, so the VM will just do it.) > > In addition to the explicitness benefits, now atomicity works uniformly > across B2 and B3, ref and val. Not only does this eliminate the asymmetries, > but it means that classes that are B2 because they don’t have a good default, > can *routinely get better flattening* than they would have under the status > quo straw man; previously there was a big flattening gap, even with heroics > like stuffing four ints into 128 bit atomic loads. When the user says “this > B2 is non-atomic”, we can immediately go full-flat, maybe with some extra > footprint for null. As a specific example, yes, there are some advantages to non-atomic B2s. But at the cost of disrupting the notion that B2 instances are always objects, and objects are, naturally, safely encapsulated. Would we say that objects are not necessarily atomic anymore? Or that these B2 instances aren't objects? My inclination would probably be to abandon the object/value dichotomy, revert to "everything is an object", perhaps revisit our ideas about conversions/subtyping between ref and val types, and develop a model that allows tearing of some objects. Probably all do-able, but I'm not sure it's a better model. If the main goal here is to have an intuitive story that minimizes surprises, I'm currently pretty happy with (all terms here subject to further bikeshedding): - Primitive classes (or just "primitives") have primitive value instances - Like the primitives you know, these tend to be stored directly in memory - Like the primitives you know, because of their storage sometimes there's a risk of tearing - If you're declaring a multi-field primitive, you need to understand this risk and choose whether to allow tearing (via 'atomic' or 'non-atomic') A critique here is that now we have more ad hoc "buckets", but the 'atomic' modifiers feel to me more like a minor piece of B3, not an entirely new bucket (and, bonus, a property that already exists within the space of primitives!). E.g., I can totally see javadoc having a tab for "Value Classes" and a separate tab for "Primitives", but I wouldn't expect tabs for "Atomic Primitives" and "Non-atomic Primitives". (Instead, maybe there's some boilerplate on the class page along the lines of "Note that this primitive is not atomic".)
