United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7023639 JSR 292 method handle invocation needs a fast path for compiled code
JDK-7023639 : JSR 292 method handle invocation needs a fast path for compiled code

Details
Type:
Bug
Submit Date:
2011-03-02
Status:
Closed
Updated Date:
2014-02-06
Project Name:
JDK
Resolved Date:
2012-08-11
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs24 (b20)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

                                    

Comments
PUBLIC COMMENTS

http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-March/002550.html
                                     
2011-03-02
EVALUATION

We need to supply better code paths in MethodHandles::from_compiled_entry.  Currently it does the C2I adapter dance.

Compiled entry points for method handles need to be specialized to (a) the signature being called and (b) the actual set of argument transforms being performed along the MH chain.  

Part (b) doesn't need to cover all possible transforms, just the ones that are dynamically important.  (See Description for a provisional list.)

The method handle "vmentry" stubs are intended to be split (cloned and specialized) if necessary to support the compiled paths.

As a more difficult optimization, it would also be possible to push the vmentry field into the vtable, thus reducing footprint and leveraging klass-based profiling.  This should be considered along with bug 6984705, which is also likely to require a class hierarchy change.
                                     
2011-03-02
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/050116960e99
                                     
2012-07-25
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1d7922586cf6
                                     
2012-07-25
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/050116960e99
                                     
2012-08-11
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1d7922586cf6
                                     
2012-08-11
Closed as already verified during 7u12 bug verification process.
                                     
2013-08-01



Hardware and Software, Engineered to Work Together