Parametric VM class file format
forax at univ-mlv.fr
forax at univ-mlv.fr
Wed Apr 21 15:32:32 UTC 2021
----- 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.
>
>> And same question with two linkages (SpecializationLinkage).
>
> Definitely. Just like you’d want to unique-ify
> CONSTANT_Class items.
yes !
>
>> I believe the answer is yes for both, the index is shared.
>>
>> The other questions are about "ldc Linkage", first, why do we need a ldc Linkage
>> with a Linkage that reference a class given that we already have Condy ?
>
> Condy can do a lot of this stuff, but it shouldn’t duplicate
> work that the JVM is already likely to have done.
> If you have code using a C_Linkage[C_Class,] the JVM
> has probably resolved it to a species. In that case,
> a condy is wasted work.
>
> 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.
Also ldc C_Class is now subsumed by Condy, so having everything be managed by Condy may make more sense now that Condy exists.
>
>> 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 ?
>
> — John
Rémi
More information about the valhalla-spec-observers
mailing list