Be able to invoke a MethodHandle directly

[Rémi Forax]

John Rose a écrit :
> On Oct 24, 2008, at 3:13 AM, Rémi Forax wrote:
>
>   
>> During the JVM Summit, you say that BGGA closure is the major use case
>> for allowing to call a MethodHandle directly using its method  
>> "invoke".
>>     
>
> Yes, it's a major use case in case BGGA is adopted.  (Which I think  
> should happen, but that's a different conversation.)
>
> But it is not *the* major use case.  A far more direct and central  
> use case is the task of wiring up adapters and decision trees, using  
> higher-order functions (combinators).  The combinators given in the  
> JSR 292 EDR are a core set, but they are not intended to be the whole  
> toolkit.  (We can't predict what the whole toolkit will be.)
>   
as usual, when you provide a tool, users use it in a way you never 
imagine :)
> In general, you use MHs.insertArgument to build bound method handles  
> to perform language-specific adaptation and dispatch.  The attached  
> code (using the bound-in data to fill in free variables) needs to  
> perform the language-specific tests and conversions.  Perhaps it also  
> attaches language specific control blocks, as implicit arguments.   
> Eventually the target method gets called, after all the tests and  
> argument adjustments.  That invocation point is a direct MH.invoke call.
>   
Yes but this call isn't a real direct call, i.e it's a call
done as a result of findVirtual(), unreflect(), etc.
These calls are done by adapters not directly
(btw you don't answer to my question about user-defined method handle
with inconsistent method type).
> Basically, if you want to build combinators, you need (a) bound  
> method handles and (b) direct MH.invoke calls.  Step (a) creates the  
> wrapper that gets called, and step (b) calls the next guy in line.   
>   
I don't know if your remember my pathetic presentation ( :) ) but in the
backport there is no line, all is flatten before being called and 
transformed
to one bytecode blob to preserve "inlining budget" (charles, i love that 
expression).

> This is a sort of tinkertoy set that can be used to build any needed  
> structure.  BMH creation is one kind of connection point, and  
> MH.invoke is the complementary end.
>
>   
>> I don't think it's a good example since BGGA closures are
>> covariant/contravariant,
>> so the MethodHandle behind a closure can't be called directly  
>> because it
>> need to be adapted.
>>     
>
> The adaptation is (in the EDR) a hardwired case, because (it is  
> likely) the JVM can optimize it easily.  The adaptation could also be  
> expressed as a user-written BMH.  Anything more complicated than a  
> Java implicit conversion *will* be expressed with a user-written BMH.
>   
I don't believe in user-written BMH. A user have to deal with different
method types (object vs primitive, number of arguments, etc)
which is merly impossible if you don't box everything  in an array as 
reflection do.
That why i have proposed a new method handle adapter to write combinator:
see http://mail.openjdk.java.net/pipermail/mlvm-dev/2008-October/000236.html
>   
>> So I don't see a 'real' use case for calling a MethodHandle directly.
>>
>> For the backport, emulate this call is a performance problem because
>> unlike invokedynamic that requires to use  
>> Linkage.registerBootstrapMethod()
>> on classes that contains at least one invokedynamic call site
>> there is no such requirement for MethodHandle.invoke()
>> a MethodHandle.invoke can be done anywhere
>> so I have to inspect all loaded classes.
>>     
>
> Check the constant pool for Methodrefs of  
> java.dyn.MethodHandle.invoke.  If they don't appear, then don't scane  
> the rest of the class.
>   
good idea.
> Thanks, Remi.
>
> -- John
>   
Thanks, John.

Rémi