[External] : Re: Parametric VM class file format

[John Rose]

On Apr 21, 2021, at 8:32 AM, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "John Rose" <john.r.rose at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
>> Envoyé: Mercredi 21 Avril 2021 08:43:34
>> Objet: Re: Parametric VM class file format
> 
>> On Apr 20, 2021, at 9:40 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> Hi all,
>>> at least as an exercise to understand the proposed class file format for the
>>> parametric VM, i will update ASM soon (in a branch) to see how things work.
>> 
>> Thank you!
>> 
>>> As usual with ASM, there is the question of sharing the same index in the
>>> constant pool,
>>> i.e. should two anchors (SpecializationAnchor) that have the same kind and the
>>> same BSM + constant arguments share the same constant pool index ?
>> 
>> Yes, I don’t see why not.  For a Class-level SA it would
>> be a bug if there were two of them in one classfile.
> 
> 
> As i said earlier, I hope the spec will say that you can have more than one SpecializationAnchor with the kind class, given that only one will be used by the VM, the one referenced by the Parametric attribute at class level.

I added this:

> It is permitted for a constant pool to contain
`CONSTANT_SpecializationAnchor` items which are unused.  But typically
a `PARAM_Class` anchor, if it exists, will be unique in its `class`
file, and be referenced by the `Parametric` attribute of the class,
and other anchors will be used to assign parametricity to the class's
methods, either singly or in groups.  It is highly probable that two
specialization anchors with the same kind and bootstrap method are in
fact interchangeable: Just as with `CONSTANT_Dynamic`, there is no
intention to provide "hooks" for structurally identical constants that
have different meanings.
> 
>> We did without ldc C_Class for a while but added it
>> for similar reasons.  Once we added it we had no
>> desire to go back to the workarounds.  I predict the
>> same for “C_Species” which is C_Linkage[C_Class,].
> 
> It may not be a problem but it means that ArrayList<String>.class is represented by C_Linkage[C_Class] while ArrayList<T>.class is represented by Condy[C_Class, C_SpecializationAnchor] which is not very symmetric.

The asymmetry is intentional because T is not a named
entity in the JVM while every class is.  As the document
says, we can consider adding CP sugar to perform common
tasks, such as reifying a type parameter from a specialization
anchor, but for now condy is our friend.

(It occurs to me that we *might* do, as sugar, CLR-like
syntaxes where an internal constant CONSTANT_Class[T1;]
could be specially decoded into some sequence of hardwired
operations that go and fetch something at position 1 in some
local specialization anchor.  The bigger adventure of putting
T1; into descriptors, making an even more CLR-like system,
will have to wait a long time.  What we are building has
fewer magic names, and more metaprogramming, than
CLR generics.)

> Also ldc C_Class is now subsumed by Condy, so having everything be managed by Condy may make more sense now that Condy exists.

But why?  If I have a nice little nail file C_Class
why should I reach for my chainsaw C_Condy?

> 
>> 
>>> And second question, is there a ldc Linkage with the linkage referencing
>>> something else than a class ?
>> 
>> No!  It would be possible to find a meaning for such
>> a thing, but it would probably interfere with ldc
>> of C_Linkage[C_Class,].  (I tried.)  The workaround
>> is not bad:  Just wrap the C_Linkage[C_Methodref]
>> in a C_MethodHandle, et voilà.
>> 
>> An earlier draft made ldc of a C_Linkage recover
>> the SpecializationAnchor object, with the theory
>> that from there condy gets you everything.  But
>> I turned away from that design because (a) it was
>> clunky to use, and (b) it exposed SA objects which,
>> as I came to understand, should really be encapsulated
>> and private to their defining class.
> 
> ahh, i'm lost, it's not clear to me if a SpecializationAnchor can be a bootstrap constant or not ?

(Is there a residual place in the doc which seems to say that
it would be good to ldc a C_Linkage?  I thought I removed
all of those statements.)

Anyway, you can ldc a C_Anchor and/or observe it in a BSM,
and that’s how you start the metaprogramming adventure:

> A `CONSTANT_SpecializationAnchor` constant is a (new sort of) loadable
> constant (§5.1).  The resolved value of this constant is a mirror to a
> set of specialization decisions, also called a `SpecializationAnchor`
> (§4.1).

Then you look at the rather wide SA API, and condy is
your friend from there on.  If we want, we can add more
sugar, but first we should go light on sugar.

— John