JDK-7023639 : JSR 292 method handle invocation needs a fast path for compiled code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-03-02
  • Updated: 2019-06-19
  • Resolved: 2012-08-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u40Resolved 8Fixed hs24Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
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.

Closed as already verified during 7u12 bug verification process.

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1d7922586cf6

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

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

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

PUBLIC COMMENTS http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-March/002550.html

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.