Be able to invoke a MethodHandle directly

[John Rose]

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

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.

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

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

Thanks, Remi.

-- John