performance issue: 7023639: JSR 292 method handle invocation needs a fast path for compiled code

[John Rose]

It took us years to learn to optimize calls to Java methods.  Now we are beginning to learn how to optimize uses of method handles.  This new learning curve won't take as long as the old one, since we can reuse our existing knowledge.  But it won't be instantaneous either.  I expect both JDK 7 and JDK 8 to include important performance improvements to method handles and invokedynamic.

To help us track our progress and manage our tuning work, we will (from time to time) file issues having to do with JSR 292 performance.

Issue 7023639 applies to people who are using method handles as function pointers for Java.  If this affects your use of 292, please let us know.

Other issues likely to arise have to do with performance disparities between method handles obtained from MethodHandles.Lookup and the corresponding bytecoded and reflective operations.

Onward!

-- John Rose

P.S. Here's the bug text:

7023639 JSR 292 method handle invocation needs a fast path for compiled code

This is a tracking issue for calls to non-constant method handles to and from "hot" compiled code.

Internally to the JVM, method handle argument list transformations are implemented on the interpreter stack.  This means that when compiled code invokes a method handle with argument transforms, it goes through a C2I adapter, transforms the argument list in interpreted format, and then (presumably) goes through an I2C adapter.

At least the most important transforms should go through customized code.  These include:
- direct access (no transforms)
- receiver binding (the bindTo transformation)
- trivial asType transformations
- invokeGeneric (argument and return value conversions to and from Object)

Probably all of the core transforms on MethodHandle virtual methods (not necessarily MethodHandles static methods) should get favorable treatment for compiled-to-compiled calls.

An important customer is Project Lambda, which should be using method handles in preference to anonymous classes.  Getting the above paths right for compiled code will enable this choice.

Note that this bug does not apply to users invokedynamic, since method handles at invokedynamic call sites are routinely inlined into optimized code.