Valhalla basic concepts / terminology
kevinb at google.com
Fri May 22 20:45:24 UTC 2020
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.
> 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,
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
> 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
More information about the valhalla-spec-observers