(somehow two versions of this got sent, along with some cut and paste from
another thread; please disregard whatever looks weird.)
> On Apr 27, 2022, at 5:50 PM, Brian Goetz <brian.go...@oracle.com> wrote:
>
> Let me try and put some more color on the bike shed (but, again, let’s focus
> on model, not syntax, for now.)
>
> We have two axes of variation we want to express with non-identity classes:
> atomicity constraints, and whether there is an additional zero-default
> companion type. These can be mostly orthogonal; you can have either,
> neither, or both. We've been previously assuming that "primitiveness" lumps
> this all together; primitives get more flattening, primitives can be
> non-nullable/zero-default, primitives means the good name goes to the "val"
> type. Primitive-ness implicitly flips the "safety vs performance" priority,
> which has been bothering us because primitives also code like a class. So we
> were trying to claw back some atomicity for primitives.
>
> But also, we're a little unhappy with B2 because B2 comes with _more_
> atomicity than is necessarily needed; a B2 with no invariants still gets less
> flattening than a B3. That's a little sad. And also that it seems like a
> gratuitous difference, which makes the user model more complicated. So we’re
> suggesting restacking towards:
>
> - Value classes are those without identity
> - Value classes can be atomic or non-atomic, the default is atomic (safe by
> default)
> - Value classes can further opt into having a "val" projection (name TBD, val
> is probably not it)
> - Val projections are non-nullable, zero-default — this is the only difference
> - Both the ref and val projections inherit the atomicity constraints of the
> class, making atomicity mostly orthogonal to ref/val/zero/null
>
> Example: classic B2
>
> value class B2a { }
>
> Because the default is atomic, we get the classic B2 semantics -- no
> identity, but full final field safety guarantees. VM has several strategies
> for flattening in the heap: single-field classes always flattened (“full
> flat”), multi-field classes can be flattened with "fat load and store"
> heroics in the future (“low flat”), otherwise, indirection (“no flat”)
>
> Example: non-atomic B2
>
> non-atomic value class B2n { }
>
> Here, the user has said "I have no atomicity rquirements." A B2n is a loose
> aggregation of fields that can be individually written and read (full B3-like
> flattening), with maybe an extra boolean field to encode null (VM's choice
> how to encode, could use slack pointer bits etc.)
>
> Example: atomic B3
>
> zero-capable value class B3a { }
>
> This says I am declaring two types, B3a and B3a.zero. (The syntax in this
> quadrant sucks; need to find better.) B3a is just like B2a above, because we
> haven’t activated the zero capability at the use site.
> B3a.zero/val/flat/whatever is non-nullable, zero-default, *but still has full
> B2-classic atomicity*. With the same set of flattening choices on the part
> of the VM.
>
> Example: full primitive
>
> non-atomic zero-capable value class B3n { }
>
> Here, B3n is like B2n, and B3n.zero is a full classic-B3 Q primitive with
> full flattening.
>
> So:
>
> - value-ness means "no identity, == means state equality"
> - You can add non-atomic to value-ness, meaning you give up state integrity
> - You can orthogonally add zero-capable to value-ness, meaning you get a
> non-null, zero-happy companion, which inherits the atomic-ness
>
> Some of the characteristics of this scheme:
>
> - The default is atomicity / integrity FOR ALL BUCKETS (safe by default)
> - The default is nullability FOR ALL BUCKETS
> - All unadorned type names are reference types / nullable
> - All Val-adorned type names (X.val) are non-nullable (or .zero, or .whatever)
> - Atomicity is determined by declaration site, can’t be changed at use site
>
> The main syntactic hole is finding the right spelling for "zeroable" / .val.
> There is some chance we can get away with spelling it `T!`, though this has
> risks.
>
> Spelling zero-happy as any form of “flat” is probably a bad idea, because B2
> can still be flat.
>
> A possible spelling for “non-atomic” is “relaxed”:
>
> relaxed value class B3n { }
>
> Boilerplate-measurers would point out that to get full flattening, you have
> to say three things at the declaration site and one extra thing at the use
> site:
>
> relaxed zero-happy value class Complex { }
> …
> Complex! c;
>
> If you forget relaxed, you might get atomicity (but might not cost anything,
> if the value is small.) If you forget zero-happy, you can’t say `Complex!`,
> you can only say Complex, and the compiler will remind you. If you forget
> the !, you maybe get some extra footprint for the null bit. None of these
> are too bad, but the verbosity police might want to issue a warning here.
>
> It is possible we might want to flip the declaration of zero-capable, where
> classes with no good default can opt OUT of the zero companion, rather than
> the the other way around:
>
> null-default value class LocalDate { }
>
> which says that LocalDate must use the nullable (LocalDate) form, not the
> non-nullable (LocalDate.val/zero/bang) form.
>
>
> On 4/22/2022 2:24 PM, Brian Goetz wrote:
> I think I have a restack of Dan's idea that feels like fewer buckets.
>
> We have two axes of variation we want to express with flattenable types:
> atomicity constraints, and whether there is an additional zero-default
> companion type.
>
> We've been assuming that "primitiveness" lumps this all together; primitives
> get more flattening, primitives can be non-nullable/zero-default, primitives
> means the good name goes to the "val" type. Primitive-ness implicitly flips
> the "safety vs performance" priority, which is bothering us because
> primitives also code like a class. So we're trying to claw back some
> atomicity for primitives.
>
> But also, we're a little unhappy with B2 because B2 comes with _more_
> atomicity than is necessarily needed; a B2 with no invariants still gets less
> flattening. That's a little sad. Let's restack the pieces (again).
>
> - Value classes are those without identity
> - Value classes can be atomic or non-atomic, the default is atomic (safe)
> - Value classes can further opt into having a "val" projection (name TBD, val
> is probably not it)
> - Val projections are non-nullable, zero-default
> - Both the ref and val projections inherit the atomicity constraints of the
> class, making atomicity mostly orthogonal to ref/val/zero/null
>
> Example: classic B2
>
> value class B2 { }
>
> Because the default is atomic, we get the classic B2 semantics -- no
> identity, but full final field safety guarantees. VM has several strategies
> for flattening in the heap: single-field classes always flattened,
> multi-field classes can be flattened with "fat load and store" heroics in the
> future, otherwise, indirection.
>
> Example: non-atomic B2
>
> non-atomic value class B2a { }
>
> Here, the user has said "I have no atomicity rquirements." A B2a is a loose
> aggregation of fields that can be individually written and read (full B3-like
> flattening), with maybe an extra boolean field to encode null (VM's choice
> how to encode.)
>
> Example: atomic B3
>
> zero-capable value class B3a { }
>
> This says I am declaring two types, B3a and B3a.zero. (These names suck;
> need better ones.) B3a is just like B2 above. B3a.zero is non-nullable,
> zero-default, *but still has full B2-classic atomicity*. With the same set
> of flattening choices.
>
> Example: full primitive
>
> non-atomic zero-capable value class B3b { }
>
> Here, B3b is like B2a, and B3b.zero is a full classic-B3 Q primitive with
> full flattening.
>
>
> So the stacking is:
>
> - value-ness means "no identity, == means state equality"
> - You can add non-atomic to value-ness, meaning you give up state integrity
> - You can orthogonally add zero-capable to value-ness, meaning you get a
> non-null, zero-happy companion
>
> This is starting to feel more honest....
>
>
>
>
>
> On 4/19/2022 6:45 PM, Brian Goetz wrote:
> By choosing to modify the class, we are implicitly splitting into Buckets 3a
> and 3n:
>
> - B2 gives up identity
> - B3a further gives up nullity
> - B3n further gives up atomicity
>
> Which opens us up to a new complaint: people didn't even like the B2/B3 split
> ("why does there have to be two"), and now there are three.
>
> Given that atomic/non-atomic only work with primitive, maybe there's a way to
> compress this further?
>
> On 4/19/2022 6:25 PM, Dan Smith wrote:
> On Apr 19, 2022, at 2:49 PM, Brian Goetz <brian.go...@oracle.com>
> wrote:
>
> So, what shall we do when the user says non-atomic, but the constructor
> expresses a multi-field invariant?
>
> Lint warning, if we can detect it and that warning is turned on.
>
>
> On Apr 19, 2022, at 3:22 PM, Brian Goetz <brian.go...@oracle.com>
> wrote:
>
> Stepping back, what you're saying is that we manage atomicity among a subset
> of fields by asking the user to arrange the related fields in a separate
> class, and give that class extra atomicity. If we wanted to express
> ColoredDiagonalPoint, in this model we'd say something like:
>
> non-atomic primitive ColoredDiagonalPoint {
> private DiagonalPoint p;
> private Color c;
>
> private atomic primitive DiagonalPoint {
> private int x, y;
>
> DiagonalPoint(int x, int y) {
> if (x != y) throw;
> ...
> }
> }
> }
>
> Right?
>
> Yep. Good illustration of how just providing a class modifier gives
> programmers significant fine-grained control.
>
>
> We exempt the single-field classes from having an opinion. We could also
> exempt primitive records with no constructor behavior.
>
> Yeah, but (1) hard to identify all assumed invariants—some might appear in
> factories, etc., or informally in javadoc; and (2) even in a class with no
> invariants, it's probably useful for the author to explicitly acknowledge
> that they understand tearing risks.
>
>
> What it gives up (without either a change in programming model, or compiler
> heroics), is the ability to correlate between user-written invariants and the
> corresponding atomicity constraints, which could guide users away from
> errors. Right?
>
> Right. Could still do that if we wanted, but my opinion is that it's too much
> language surface for the scale of the problem. If we did have additional
> construction constraints, I'd prefer that atomic primitives allow full
> imperative construction logic & encapsulation.
>
> This feels analogous to advanced typing analyses that might prove certain
> casts to be safe/unsafe. Sure, the language could try to be helpful by
> implementing that analysis, but it would add lots of complexity, and
> ultimately it's either a best-effort check or annoyingly restrictive.
>
>> On Apr 27, 2022, at 2:51 PM, Dan Heidinga <heidi...@redhat.com> wrote:
>>
>> I'm trying to understand how this refactoring fits the VM physics.
>>
>> In particular, __non-atomic & __zero-ok fit together at the VM level
>> because the VM's natural state for non-atomic (flattened) data is zero
>> filled. When those two items are decoupled, I'm unclear on what the
>> VM would offer in that case. Thoughts?
>>
>> How does "__non-atomic __non-id class B2a { }" fit with the "no new
>> nulls" requirements?
>>
>> --Dan
>>
>> On Wed, Apr 27, 2022 at 12:45 PM Brian Goetz <brian.go...@oracle.com> wrote:
>>>
>>> Here’s some considerations for stacking the user model. (Again, please
>>> let’s resist the temptation to jump to the answer and then defend it.)
>>>
>>> We have a stacking today which says:
>>>
>>> - B1 is ordinary identity classes, giving rise to a single reference type
>>> - B2 are identity-free classes, giving rise to a single reference type
>>> - B3 are flattenable identity-free classes, giving rise to both a reference
>>> (L/ref) and primitive (Q/val) type.
>>>
>>> This stacking has some pleasant aspects. B2 differs from B1 by “only one
>>> bit”: identity. The constraints on B2 are those that come from the lack of
>>> identity (mutability, extensibility, locking, etc.) B2 references behave
>>> like the object references we are familiar with; nullability, final field
>>> guarantees, etc. B3 further makes reference-ness optional; reference-free
>>> B3 values give up the affordances of references: they are zero-default and
>>> tearable. This stacking is nice because it can framed as a sequence of
>>> “give up some X, get some Y”.
>>>
>>> People keep asking “do we need B2, or could we get away with B1/B3”. The
>>> main reason for having this distinction is that some id-free classes have
>>> no sensible default, and so want to use null as their default. This is a
>>> declaration-site property; B3 means that the zero value is reasonable, and
>>> use sites can opt into / out of zero-default / nullity. We’d love to
>>> compress away this bucket but forcing a zero on classes that can’t give it
>>> a reasonable interpretation is problematic. But perhaps we can reduce the
>>> visibility of this in the model.
>>>
>>> The degrees of freedom we could conceivably offer are
>>>
>>> { identity or not, zero-capable or not, atomic or not } x { use-site,
>>> declaration-site }
>>>
>>> In actuality, not all of these boxes make sense (disavowing the identity of
>>> an ArrayList at the use site), and some have been disallowed by the
>>> stacking (some characteristics have been lumped.) Here’s another way to
>>> stack the declaration:
>>>
>>> - Some classes can disavow identity
>>> - Identity-free classes can further opt into zero-default (currently, B3,
>>> polarity chosen at use site)
>>> - Identity-free classes can further opt into tearability (currently, B3,
>>> polarity chosen at use site)
>>>
>>> It might seem the sensible move here is to further split B3 into B3a and
>>> B3b (where all B3 support zero default, and a/b differ with regard to
>>> whether immediate values are tearable). But that may not be the ideal
>>> stacking, because we want good flattening for B2 (and B3.ref) also.
>>> Ideally, the difference between B2 and B3.val is nullity only (Kevin’s
>>> antennae just went up.)
>>>
>>> So another possible restacking is to say that atomicity is something that
>>> has to be *opted out of* at the declaration site (and maybe also at the use
>>> site.) With deliberately-wrong syntax:
>>>
>>> __non-id class B2 { }
>>>
>>> __non-atomic __non-id class B2a { }
>>>
>>> __zero-ok __non-id class B3 { }
>>>
>>> __non-atomic __zero-ok __non-id class B3a { }
>>>
>>> In this model, you can opt out of identity, and then you can further opt
>>> out of atomicity and/or null-default. This “pulls up” the
>>> atomicity/tearaiblity to a property of the class (I’d prefer safe by
>>> default, with opt out), and makes zero-*capability* an opt-in property of
>>> the class. Then for those that have opted into zero-capability, at the use
>>> site, you can select .ref (null) / .val (zero). Obviously these all need
>>> better spellings. This model frames specific capabilities as modifiers on
>>> the main bucket, so it could be considered either a two bucket, or a four
>>> bucket model, depending on how you look.
>>>
>>> The author is in the best place to make the atomicity decision, since they
>>> know the integrity constraints. Single field classes, or classes with only
>>> single field invariants (denominator != 0), do not need atomicity. Classes
>>> with multi-field invariants do.
>>>
>>> This differs from the previous stacking in that it moves the spotlight from
>>> _references_ and their properties, to the properties themselves. It says
>>> to class writers: you should declare the ways in which you are willing to
>>> trade safety for performance; you can opt out of the requirement for
>>> references and nulls (saving some footprint) and atomicity (faster access).
>>> It says to class *users*, you can pick the combination of characteristics,
>>> allowed by the author, that meet your needs (can always choose null default
>>> if you want, just use a ref.)
>>>
>>> There are many choices here about “what are the defaults”. More opting in
>>> at the declaration site might mean less need to opt in at the use site. Or
>>> not.
>>>
>>> (We are now in the stage which I call “shake the box”; we’ve named all the
>>> moving parts, and now we’re looking for the lowest-energy state we can get
>>> them into.)
>>>
>>
>
