Valhalla basic concepts / terminology

[Kevin Bourrillion]

On Fri, May 22, 2020 at 12:37 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>    - There are two kinds of objects/instances; the notions "object" and
>    "instance" apply equally to both kinds. These are "inline objects" and
>    "identity objects". Statements like "it's an instance, so that means it's
>    on the heap" and "you can lock on any object" become invalid, but
>    statements like "42 is an instance of `int`" *are* valid.
>
> Correct.
>
> From a pedagogical perspective, it's not clear whether we are better off
> framing it as a partitioning (there are two kinds, red and blue) or that
> some objects have a special property (in addition to their state, some
> objects have a special hidden property, its identity.)
>
> We have been going down the former path, but I am starting to think the
> latter path is more helpful; rather than cleaving the world of objects in
> two, instead highlight how some (many!) objects are "special".
>

Well, for quite a while, the major audience will be people who knew an
earlier version of Java, and I think they already have the "red/blue"
model. I do think we will mostly get away with "we're just broadening that
red, from just 8 specific shades of off-crimson ..."


>    - (do we intend to use the term "object", or use the term "instance",
>       or define the two differently somehow?)
>
> To the extent we can avoid redefining these things, I think it is easier
> to just leave these terms in place.
>

Uh oh, this makes me worry that I'm already supposed to know what the
distinction is. :-)
In my everyday experience, people sometimes use "object" ambiguously to
refer to the instance or the class, but "instance" to emphasize the, err,
instance.
Is that it?


>    - Identity objects get the benefits of identity, at the cost that you
>    may only store *references* to them. They will ~always go onto the
>    heap (modulo invisible vm tricks).
>
> Yes.  Again, pedagogically, I am not sure whether the heap association is
> helpful or hurtful; on the one hand, C programmers will understand the
> notion of "pointer to heap node", but on the other, this is focusing on
> implementation details, not concepts.
>

*But is* it an implementation detail? To me, this entire feature is about
memory layout on its face.


>    - (Users choose by e.g. writing either `Foo.val` or `Foo.ref`, though
>       one would be the default)
>
> Yes.  It is worth noting here that we would like for the actual incidence
> of `.ref` and `.val` in real code to be almost negligible.  Maurizio likens
> them to "raw types", in the sense that we need them to complete the type
> system, and there are cases where they are unavoidable, but the other 99.9%
> of the time, you just say "Point".
>

This aspiration strikes me as highly... aspirational. :-) Isn't the user
pushed into this the second they call `Map.get()`?


>    - We can also sort concrete classes into just two groups: "inline
>    classes" and "identity classes", each of which begets only its own kind of
>    objects/instances.
>
> Yes.  All the instances of a class C are either identity objects, or
> inline objects.
>

(I was saying the stronger form "either-they're-all", not just
"all-are-either", but I don't think we're actually disagreeing. Talking
only of concrete classes.)


>    We don't say "value types" anymore because the term "value" (as in
>    "value set") applies to *all* types.
>
> Yes.  The appeal of "value" comes from "pass by value", but there is too
> much baggage associated with the word value.
>
> The choice of inline is not perfect; it's a strange word to most people,
> but it comes with the intuition that an inline object's layout will be
> "inlined" into containing objects/arrays.  But, it doesn't mean that its
> methods will always be inlined (though that is more likely as they are
> final and the VM will have sharp type information.)
>

Well, I love the name, regardless.


>    - A concrete *class* is either an "identity class" or an "inline
>    class". But a compile-time *type* is distinguished not by "inline vs
>    identity" but by "inline vs *reference*".
>
> Yeah, this is the other hard one.  In fact, it took us years to realize
> that the key distinction is not reference vs primitive/inline, but
> _identity_ vs inline.
>

Did I have it backwards?



> Here's the scorecard:
>
> Object is a reference type.
> For an identity or abstract class C, C is a reference type.
> For an interface I, I is a reference type.
> For an inline class V, V is an inline type.
> Primitives are inline types.
>
> A reference type always holds a reference to an object (which might be
> inline or identity), or null.
>

Okay, this is waay better than the junk I typed out, which I realize now
didn't even make sense. Ugh,

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com