Valhalla basic concepts / terminology
kevinb at google.com
Tue Jun 9 23:00:39 UTC 2020
On Tue, Jun 9, 2020 at 2:18 PM Dan Smith <daniel.smith at oracle.com> 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 google.com
More information about the valhalla-spec-observers