FTR: JVM Lang Summit presentation
forax at univ-mlv.fr
Fri Sep 19 21:58:48 UTC 2014
On 09/19/2014 07:13 PM, John Rose wrote:
> On Sep 18, 2014, at 2:20 AM, Remi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
>> also note that we only need overloads for signature, if we use indy,
>> we can have
>> several overloads but one implementation.
> That's why I have been casting about for some way to express
> indy-binding for VarHandle APIs (instead of the sig-poly binding of
> VHs in Paul's prototype).
An annotation on the method declaration.
A meta-annotation on the annotation that specify the BSM.
Meta-protocol: a call to an annotated method is translated to an
invokedynamic, the descriptor of indy is inferred from the type of the
arguments (like with a polymorphic signature), the return type is the
return type of the annotated method (may be a cast can override this
behavior). If the annotated method is not abstract,
the annotated method is sent as a bootstrap argument.
> Indy provides caller-side signature polymorphism, and leaves the
> binding up to a factory somewhere, which might be as simple as a
> MH.asType call to take the polymorphism away, or could be something
> I also think that the asType transform is a good starting point for
> expressing instantiation of parametric polymorphism.
Let see, the JIT will prefer the types propagated from the callsite to
the profile types.
The compiler will have to use v-opcodes (opcodes depend on either the
types on stack or the type of the local variables).
There is still the problem of opcodes that embed specified types like
getfield/invoke*, instanceof, checkcast, anewarrray
or worst a lambda that use a parametrized functional interfaces (in that
case, the BSM args of invokedynamic also need to be specialized).
> — John
More information about the valhalla-dev