FTR: JVM Lang Summit presentation

[Remi Forax]

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 
> fancier.
>
> 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

Rémi