Valhalla basic concepts / terminology

Kevin Bourrillion kevinb at
Tue Jun 9 23:00:39 UTC 2020

On Tue, Jun 9, 2020 at 2:18 PM Dan Smith <daniel.smith at> wrote:

A few things that still make me a bit uneasy, maybe could use more noodling:
> - "Inline value" vs. "reference value" makes sense. Then re-using "inline"
> for "inline class" vs. "identity class" is potentially confusing. In this
> context, we're using "inline" as shorthand for "inline-capable" and
> "identity-free". It would sort of be nice if we could flip the world and
> make 'identity' the class declaration keyword (although we'd still need a
> term for the absence of that keyword).

My current way of spinning this to myself is that a class being "inline"
means it *enables* possible inlining, *and* that referring to it as an
"inline" type (its concrete type) is another step that also *enables* possible
inlining, and in the end the VM will do what it wants, subject to those
limitations. So, I can see the term working at both levels...

- The syntax ".val" used to denote an "inline type" is a bit of a mismatch.
> Maybe we want a new syntax. Or maybe we want to rework the word "value"
> into the story so that "inline type" becomes "value type".

This was my reaction too. ".val" means "the value itself, that you care
about", and ".ref" means "a reference value that points to the value you
care about", but I used the word "value" *more* times in the second phrase.
It doesn't feel like this will be clear.

> - The term "class type" now has multiple possible interpretations. I
> guess, unless it's qualified further, it ought to refer to all types
> "derived from" a particular class, including reference types, inline types,
> parameterized types, raw types, ... The taxonomy of types, including
> appropriate terms, needs to be sorted out.
> - I'm ignoring generic inline classes. We're all ignoring generic inline
> classes. :-) Generics in the inline type world are, I think, a somewhat
> different beast than generics in the reference type world, because inline
> types are disjoint. More work to be done here.

I haven't had a chance to learn much about this or give it much thought,
but here's my naive thoughts/questions:

   - Type parameters that are identity-bounded (or get marked as
   identity-bounded) work like always, even in a generic inline class, not
   much trouble there?
   - Existing code would mostly work for inline types via their reference
   projections, but identity stuff would fail at runtime, and of course
   performance gains are left on the table
   - If you could declare a type parameter as inclusive of inline types you
   could at least move some runtime failures to compile-time
   - But I don't see how to get performance benefits of flattening unless
   these generics are reified somehow?

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

More information about the valhalla-spec-observers mailing list