where are all the objects?

[John Rose]

On 10 Aug 2022, at 12:34, Brian Goetz wrote:

> On 8/10/2022 3:17 PM, Dan Heidinga wrote:
>> Which fits with the VAO model.  Object references are clearly our 
>> giraffe leashes but that doesn't give us a good word for the 
>> flattened papery giraffe itself.  The challenge here is we're not 
>> describing a property of the thing, we're describing the lack of 
>> something (the leash or reference).  Add to this the VM doesn't 
>> provide guarantees about the storage for the non-reference case - 
>> it's all VM discretion on whether to flatten or not - so 
>> accurate terms feel like weasel words.
>>
>> Does the VAO model feel less forced if we're explicit about 
>> references being the difference?
>>  - A value object can also be represented without an object 
>> reference, as primitives are today   // (*)
>>
>
> This is actually the new weirdness --
> that you have a choice about how to handle a value object.  
> Previously we had two kinds of things: primitives (direct values) and 
> object references (which can be null, or can have an object at the end 
> of them, but you can't touch the object, only the reference.)  Now we 
> still have two kinds of values: value objects, and object references 
> --
> but object references can also refer to value objects!  This is the 
> weird part; that value objects have two separate placements / 
> representations / interaction modes.  We got away before without a 
> notion of "bare object" because the only way you could touch a 
> primitive is directly, and the only way you could touch an object is 
> through a reference.  But now some objects can be touched directly, 
> *or* through a reference.
>
> C programmers would say "Duh, that's just X vs X*", but we want to 
> blur the difference, so we don't distinguish between `x.a` and `x->a` 
> as we do in C.
>
> Brainstorming on terms....we haven't tried "unboxed".
>
>  - A Point.ref is a reference to a Point object
>  - A Point.val is an unboxed Point object

The issue with many of these formulations (like “unboxed Point”) is 
that it makes it sound like the Point object has a funny decoration on 
it that makes it be unboxed.  But what we want to say (I think) is that 
it is unburdened by any such decoration.  That’s why I like a “just 
the facts” Point:   “pure Point” or “bare Point” or “simple 
Point” or “unadorned Point”.  Or maybe, suggesting the lack of an 
intermediary, “immediate Point” or “direct Point”.

> This fits into the "reference as default" model, but it suggests that 
> Point.val are *not* objects, they are the "scooped out filling" of an 
> object.  So I guess this is more of a VANO term.  Oh well.

Yeah; it seems to damage the integrity (simplicity, purity) of the Point 
to say, “oh that’s a spilled point”.  (Spilled = unboxed.)

>
> Is there any mileage in splitting "reference" instead of object? Like, 
> a "lightweight reference" (a short leash), which doesn't support 
> polymorphism or null?  Then a Point.val is a "lightweight reference" 
> to a Point?

I think there is some mileage there for specifications, if not for 
teaching and learning.  That’s why I suggested “value arrows” in 
my previous.  Those are the same as your “short leash”.

> The VAO term we are looking for might be more like "grab the giraffe 
> by the collar, rather than by the leash" :)

Yes, the two-heap model suggests we could pretend that all objects 
require leashes of some sort (chopsticks), but there are short ones and 
long ones with somewhat differing operational semantics (especially for 
`==`/`acmp`).

And then, *as an optimization* but not in the specification, a 
short-leash giraffe can climb right up into your lap (if the VM lets 
it).  You know you’ll like it, since you always preferred your ints 
and bytes close at hand.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20220810/fc54ca7b/attachment-0001.htm>