Valhalla basic concepts / terminology

[Kevin Bourrillion]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20200609/aa23d296/attachment.htm>