The concern is that we need Foo.nestHost == Rational.nestHost and that
the common nestHost includes both Foo and Rational as nestMembers. To
do that, we need to load the nestHost class (if it isn't already).
Getting the interaction between the access check and the additional
class loads right
On Tue, Jun 14, 2022 at 11:29 AM Dan Heidinga wrote:
>
> On Tue, Jun 14, 2022 at 10:19 AM Brian Goetz wrote:
> >
> > It took me a while to understand your concern, but I think I have it now
> > -- it is that we're effectively doing separate access control on LFoo
> > and QFoo. At the language le
Here are two examples of where a B2 class could safely and
beneficially use B2.val:
value class Rational {
Rational[] harmonicSeq(int n) {
Rational.val[] rs = new Rational.val[n];
for (int i=0; irationals could be flat.
> From: "Brian Goetz"
> To: "Remi Forax" , "valhalla-spec-experts"
>
> Cc: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Tuesday, June 14, 2022 3:16:41 PM
> Subject: Re: User model stacking: current status
[...]
On Tue, Jun 14, 2022 at 10:19 AM Brian Goetz wrote:
>
> It took me a while to understand your concern, but I think I have it now
> -- it is that we're effectively doing separate access control on LFoo
> and QFoo. At the language level this is no problem, but the VM needs a
> story here. Is this
It took me a while to understand your concern, but I think I have it now
-- it is that we're effectively doing separate access control on LFoo
and QFoo. At the language level this is no problem, but the VM needs a
story here. Is this the whole of your concern, or is there more?
- The .val
Overall, I like this proposal. It gives us one new "thing" value
classes, and then some additional rules on exposing the zero (or not)
and right defaults for atomic-ness.
One concern, sketched out below, about using the nest for
accessibility during class loading. Mostly an area where we'll need
And with Rational.val requiring atomic access, we can only flatten it
if the underlying HW supports it (in this case, 2 ints fits nicely in
64bits so we're good). Larger .val's can only be flattened if marked
as "non-atomic" (the B3n case). And because there's no tearing,
handing out the flat
On Tue, Jun 14, 2022 at 9:17 AM Brian Goetz wrote:
>
>
> The val type for B2 should not exist at all
>
>
>
> So B2 is really a B3a whose value projection is encapsulated.
>
>
> and here you lost me, .ref and .val are supposed to be projection types not
> classes, at runtime there is only one clas
The val type for B2 should not exist at all
So B2 is really a B3a whose value projection is encapsulated.
and here you lost me, .ref and .val are supposed to be projection
types not classes, at runtime there is only one class.
And apparently I have to say this again It's fine
> From: "Brian Goetz"
> To: "daniel smith"
> Cc: "valhalla-spec-experts"
> Sent: Tuesday, June 14, 2022 1:04:39 AM
> Subject: Re: User model stacking: current status
> I've done a little more shaking of this tree. It involves keeping the
I've done a little more shaking of this tree. It involves keeping the
notion that the non-identity buckets differ only in the treatment of
their val projection, but makes a further normalization that enables the
buckets to mostly collapse away.
"value class X" means:
- Instances are identit
This makes no sense. We are not introducing a notion of reference type into the
spec. The spec is already completely riddled with the concept of references and
reference types. In fact many of the constraints that influence the current
design come from that fact.
Sent from my iPad
> On Jun 6,
> From: "Brian Goetz"
> To: "daniel smith"
> Cc: "valhalla-spec-experts"
> Sent: Friday, June 3, 2022 9:14:39 PM
> Subject: Re: User model stacking: current status
> Continuing to shake this tree.
> I'm glad we went through the ex
Continuing to shake this tree.
I'm glad we went through the exploration of "flattenable B3.ref"; while
I think we probably could address the challenges of tearing across the
null channel / data channels boundary, I'm pretty willing to let this
one go. Similarly I'm glad we went through the "a
I agree that Bucket 2 is largely uncontroversial (and largely
implemented) and makes a sensible unit of delivery -- with the proviso
that we need to properly message that it will not yet deliver the
performance improvements that most users are hoping to get out of
Valhalla. There'll be no heap
Returning to this thread and going up a level or two:
The real impact of this discussion, imho, should not be "now let's rush a
declarative nullness feature out asap", or even "let's solve bucket 3 now
in a way nullness will have to be harmonious with later". What I humbly
suggest it points to is,
I don't see the conflict. I'm saying, yeah, there *will* be exclamation
fatigue until a feature comes along eventually to relieve it. (In the worst
case, that's `public null-marked class...`; in the best case it's just
`language-level 22;` or what have you.) But I still think it's the right
thing t
* Exclamation fatigue would be very real, so assume there is some way to make
`!` the default for some scope
+1
Yes, I think it's a dead end to expect users to sprinkle '!' everywhere they
don't want nulls—this is usually the informal default in common programming
practice, so we need som
> On May 11, 2022, at 7:45 PM, Kevin Bourrillion wrote:
>
> * `String!` indicates "an actual string" (I don't like to say "a non-null
> string" because *null is not a string!*)
The thread talks around this later, but... what do I get initially if I declare
a field/array component of type 'Stri
On Thu, May 12, 2022 at 5:22 AM Brian Goetz
wrote:
- there is a nullability-injecting conversion from T! to T? (this
is a widening conversion)
I think we'd expect full subtyping here, right? It needs to work for
covariant arrays, covariant returns, type argument bounds, etc.
The
On Thu, May 12, 2022 at 5:22 AM Brian Goetz wrote:
> - there is a nullability-injecting conversion from T! to T? (this is a
> widening conversion)
>
I think we'd expect full subtyping here, right? It needs to work for
covariant arrays, covariant returns, type argument bounds, etc.
> and the
Here is my current concept of this beast:
The next installment of this is: how does assignment and conversion
work? Presumably, it starts with:
- there is a null-discarding conversion from T? to T! (this is a
narrowing conversion)
- there is a nullability-injecting conversion from T! t
On Mon, May 9, 2022 at 2:14 PM Brian Goetz wrote:
Now, let's step out onto some controversial territory: how do we spell .ref
> and .val? Specifically, how good a fit is `!` and `?` (henceforth,
> emotional types), now that the B3 election is _solely_ about the
> existence of a zero-default .val
Assuming the stacking here is satisfactory, let's talk about .ref and .val.
Kevin made a strong argument for .ref as default, so let's pull on that
string for a bit.
Universal generics need a way to express .ref at least for type
variables, so if we're going to make .ref the default, we still
> On May 9, 2022, at 10:10 AM, Kevin Bourrillion wrote:
>
>>> 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 ye
Yes, Doug posted some data a while back about sorting, where the
breakeven between sorting references and taking the indirection hit and
sorting values and taking the "more memory movement" hit was not
obvious. Flattening means ... flattening. Sometimes it means faster,
but sometimes not. Thi
> From: "Brian Goetz"
> To: "daniel smith"
> Cc: "valhalla-spec-experts"
> Sent: Sunday, May 8, 2022 6:32:09 PM
> Subject: Re: User model stacking: current status
> To track the progress of the spiral:
> - We originally came up with the B
- (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.
(Controversial with me at least; I keep thinking who are these people
who can understand the rest of how to
On Mon, May 9, 2022 at 8:52 AM Brian Goetz wrote:
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".
>
Right, and for long and dou
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 sam
On Sun, May 8, 2022 at 9:32 AM Brian Goetz wrote:
- When we put all the flesh on the bones of B2/B3, there were some
> undesirable consequences, such as (a) tearing was too subtle, and (b) both
> the semantics and cost model differences between B2/B3 were going to be
> hard to explain (and in so
To track the progress of the spiral:
- We originally came up with the B2/B3 division to carve off B2 as the
"safe subset", where you get less flattening but nulls and more
integrity. This provided a safe migration target for existing VBCs, as
well as a reasonable target for creating new VBCs
> On May 6, 2022, at 8:04 AM, Brian Goetz wrote:
>
> Thinking more about Dan's concerns here ...
>
> On 5/5/2022 6:00 PM, Dan Smith wrote:
>> This is significant because the primary reason to declare a B2 rather than a
>> B3 is to guarantee that the all-zeros value cannot be created.
>
> This
Thinking more about Dan's concerns here ...
On 5/5/2022 6:00 PM, Dan Smith wrote:
This is significant because the primary reason to declare a B2 rather
than a B3 is to guarantee that the all-zeros value cannot be created.
This is a little bit of a circular argument; it takes a property that a
Maybe :) But I don't want to prune this exploration just yet.
On 5/5/2022 6:00 PM, Dan Smith wrote:
On May 5, 2022, at 1:21 PM, Brian Goetz wrote:
Let's write this out more explicitly. Suppose that T1 writes a non-null value
(d, t, true), and T2 writes null as (0, 0, false). Then it would
Let's write this out more explicitly. Suppose that T1 writes a non-null value
(d, t, true), and T2 writes null as (0, 0, false). Then it would be possible
to observe (0, 0, true), which means that we would be conceivably exposing the
zero value to the user, even though a B2 class might wan
> On May 5, 2022, at 1:21 PM, Brian Goetz wrote:
>
> Let's write this out more explicitly. Suppose that T1 writes a non-null
> value (d, t, true), and T2 writes null as (0, 0, false). Then it would be
> possible to observe (0, 0, true), which means that we would be conceivably
> exposing the
Thanks for writing this up. I've been thinking and playing with
related ideas and this gives a clear starting point for us to work
off.
On Thu, May 5, 2022 at 3:21 PM Brian Goetz wrote:
> There are lots of other things to discuss here, including a discussion of
> what does non-atomic B2 really
There are lots of other things to discuss here, including a discussion
of what does non-atomic B2 really mean, and whether there are
additional risks that come from tearing _between the null and the
fields_.
So, let's discuss non-atomic B2s. (First, note that atomicity is only
relevant in
The current stacking discussion is motivated by several factors:
- experiences prototyping both B2 and B3
- recently discovered hardware improvements in atomic operations
(e.g., Intel's recent specification strengthening around 128-bit vector
loads and stores)
- further thought on the conseq
- Original Message -
> From: "Brian Goetz"
[...]
>
> What I'm trying to do here is decomplect flattening from nullity. Right
> now, we have an unfortunate interaction which both makes certain
> combinations impossible, and makes the user model harder to reason about.
>
> Identity-freed
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,
About six months ago we started working on flattening references in
calling conventions in the Valhalla repos. We use the Preload attribute
to force preloading of classes that are known to be (or expected to be)
value classes, but which are referenced only via L descriptors, so that
at the (ea
On 27 Apr 2022, at 16:12, Brian Goetz wrote:
> We can divide the VM flattening strategy into three rough categories (would
> you like some milk with your eclair?):
>
> - non-flat — use a pointer
> - full-flat — inline the layout into the enclosing container, access with
> narrow loads
> - low
> On Apr 27, 2022, at 7:36 PM, Kevin Bourrillion 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
On Thu, Apr 28, 2022 at 10:13 AM Brian Goetz wrote:
>
> I threw a lot of ideas out there, and people have reacted to various corners
> of them. That’s fair; it’s a lot to take in at once. Let me focus on what I
> think the most important bit of what I wrote is, which is, where we get
> permis
> From: "Kevin Bourrillion"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "Dan Heidinga"
> , "valhalla-spec-experts"
>
> Sent: Thursday, April 28, 2022 3:51:07 PM
> Subject: Re: [External] : Re: User model stacking
> On T
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Dan Heidinga" , "valhalla-spec-experts"
>
> Sent: Thursday, April 28, 2022 3:43:59 PM
> Subject: Re: [External] : Re: User model stacking
>> On Apr 28, 2022, at 9:09 AM, Remi For
I threw a lot of ideas out there, and people have reacted to various corners of
them. That’s fair; it’s a lot to take in at once. Let me focus on what I
think the most important bit of what I wrote is, which is, where we get
permission for relaxation of atomicity.
Until now, we’ve been trea
On 28/04/2022 14:51, Kevin Bourrillion wrote:
If we ride with that horse, it means that in universal generics,
we should not use T but T.val apart when we want T.val | null that
can be spelled T.
I'm not following, but again I think I'm naively assuming a type
variable might need
On Thu, Apr 28, 2022 at 9:09 AM Remi Forax wrote:
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
On Apr 28, 2022, at 9:09 AM, Remi Forax
mailto:fo...@univ-mlv.fr>> wrote:
1/ There is a difference between Foo and Foo.ref for generics, Foo is a class
while Foo.ref is a type.
The idea of using Complex.val means that the relationship is reversed,
Complex is the type and Complex.val is
> From: "Brian Goetz"
> To: "Dan Heidinga"
> Cc: "valhalla-spec-experts"
> Sent: Thursday, April 28, 2022 1:15:08 AM
> Subject: Re: [External] : Re: User model stacking
> Let me try and put some more color on the bike shed (but, again, let’s
On Wed, Apr 27, 2022 at 9:36 PM Kevin Bourrillion wrote:
(Type R) e.g. Rational, EmployeeId: the default value is illegal; can't
> even construct it on purpose. Every method on it *should* call
> `checkValid()` first. Might as well repurpose it as a pseudo-null. Bugs
> could be prevented by some
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!
I'm not sure what problem this is needed to solve.
~~
By
(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 wrote:
>
> Let me try and put some more color on the bike shed (but, again, let’s focus
> on model, not syntax, for now
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 or
We can divide the VM flattening strategy into three rough categories (would you
like some milk with your eclair?):
- non-flat — use a pointer
- full-flat — inline the layout into the enclosing container, access with
narrow loads
- low-flat — use some combination of atomic operations to cram m
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 or
- Original Message -
> From: "Dan Heidinga"
> To: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Sent: Wednesday, April 27, 2022 8:51:15 PM
> Subject: Re: User model stacking
> I'm trying to understand how this refactoring fits the
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
- Original Message -
> From: "Brian Goetz"
> To: "valhalla-spec-experts"
> Sent: Wednesday, April 27, 2022 6:44:01 PM
> Subject: User model stacking
> Here’s some considerations for stacking the user model. (Again, please let’s
> resist the tem
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
64 matches
Mail list logo
