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
41 matches
Mail list logo
