Valhalla basic concepts / terminology

Kevin Bourrillion kevinb at google.com
Fri May 22 18:54:22 UTC 2020


Hey all,

I'm sorry I've been absent from the discussion awhile. I'm liking the
direction things have been moving.

I've just caught up on the latest doc a bit. If I could reflect back to the
group what I *think* I am seeing so far, I'd really like to know where I'm
getting this right or not.

(Every word choice below is intentional in an *attempt* to be precise and
correct; please LMK if it misses the target!)


   - 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.
      - (do we intend to use the term "object", or use the term "instance",
      or define the two differently somehow?)
   - 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).
   - Inline objects forgo the benefits of identity to give you the *option* to
   store either a reference to a heap object or the data itself inline.
      - (Users choose by e.g. writing either `Foo.val` or `Foo.ref`, though
      one would be the default)
   -
   - 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.
   We don't say "value types" anymore because the term "value" (as in
   "value set") applies to *all* types.
   - 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*".
      - must hold a "reference" (or null)
   - Condition: the type (or, for a type variable, its bound): is neither
         an interface nor "almost-interface"; or is a subtype of
IdentityObject; or
         is an inline class that specifies ref-default; or bears an
explict `.ref`.
         - this is probably what the term "reference type" needs to apply
         to now. For example it is currently "reference types" that my nullness
         analysis project is concerned with and I think it would
remain that way.
         - key: it's always a reference to an instance (well, unless it's
         not null), but that might be either kind of instance.
      - must hold an inline object
         - Condition: it's a subtype of InlineObject (perhaps by being an
         `inline class` itself that is a val-default.... or by being
primitive?); or
         bears an explicit `.val`.
         - this is probably what the term "inline *type*" should refer to.
      - might hold either?
         - or can this not happen because you would be forced to write
         `.ref/.val`?
      - Primitive types *are* inline classes, full stop.
      - It's just that for compatibility reasons they get to have
      custom-built reference projections instead of only the general-purpose
      `Foo.val` treatment.

Thanks!

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


More information about the valhalla-spec-observers mailing list