generic specialization design discussion

John Rose john.r.rose at
Mon Apr 8 22:44:21 UTC 2019

On Apr 8, 2019, at 9:50 AM, Brian Goetz <brian.goetz at> wrote:
> The slide deck contains a list of terminology.  

FTR here's the relevant slide:

> “value object”, “reference object” (also value or reference instance)
> “value class”, “reference class” (also value or reference type)
> “interface class” (Object = honorary interface)
> object, class, reference: non-specific (non-primitives; ref. can be null)
> value: non-specific (includes all object references, null, all primitives)
> name (class, member), descriptor (field or method)
> resolution: a stable mapping from name to metadata (or error)
> “class template”, “method template” (even “field template”)
> “specialized class” (= "species" for short), “specialized method”
> generic parameter, hole (in template), variance (depends on hole)

If we move terms around so "value" gets replaced by "inline",
and "reference" by "indirect", only the first two lines are

“inline object”, “indirect object” (also inline or indirect instance)
“inline class”, “indirect class” (also inline or indirect type)

An inline object is inherently inline, even if it is (at the moment)
being referenced by a physical indirection.  An indirect object
is *always* referenced by a physical indirection.

I think we also want to point out (at least in the JVMS) that
the inline/indirect distinction applies to variables as well as
to objects and classes.

“inline variable”, “indirect variable” (parameter, return value, element, field, local)

There is a key bit of slippage here, where the terms don't
always line up exactly, nor do they vary freely.  You can
have any of the three but not the fourth:

an indirect variable of an indirect class
an inline variable of an inline class
an indirect variable of an inline class

At this point, we can also point out that interface classes
always have indirect variables.  Also, V? can be an indirect
type where V is an inline type.

This slippage suggests that we might try for an extra term
(or a distinct pair of terms parallel to indirect/inline) which
can apply solely to variables, or to objects, or to classes.
For example, adding "heap" instead of "indirect" for classes:

“inline object”, “heap object” (also inline or heap instance)
“inline class”, “heap class”
"inline type", "indirect type" (heap classes always indirect types)
“inline variable”, “indirect variable” (parameter, return value, element, field, local)

Choices for variables:
an indirect variable of a heap class
an indirect variable of an inline class
an inline variable of an inline class

Heap classes are always indirect types.
The natural type of an inline class is an inline type.
But an inline class has (may have?) an associated indirect type.
An interface class is always an indirect type.

This exercise appears to show that "indirect" and
"inline" are principally distinctions between variables
and their types, and only secondarily distinctions
between classes and their objects/instances.

(Variables have more degrees of freedom than
objects, because variables *view* objects, and
a single object can have several views.  We already
saw this with volatile/final/regular and now also
with inline/indirect.)

It also shows that, if we pick a third term like
"heap", it only applies to regular classes, as an
antonym for "inline", and to regular objects in
the same way.

BTW, I think primitives could be thought of as
inline types.  But not inline classes, until we invent
such things in LW200.

More information about the valhalla-spec-observers mailing list