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
> 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
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,
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 temptation to jump to the answer and then defe
50 matches
Mail list logo
