JDK-8024761 : JSR 292 improve performance of generic invocation
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-09-13
  • Updated: 2015-03-02
  • Resolved: 2013-10-05
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 8
8 b112Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The performance of MethodHandle.invoke is very slow when the call site type differs from the method handle type.  When the types differ, the invocation is defined to proceed as if two steps were taken:

1. the target method handle is first adjusted to the call site type, by MethodHandles.asType

2. the type-adjusted method handle is invoked directly, by MethodHandles.invokeExact

The existing code (from JDK 7) awkwardly performs the type adjustment on every call.  But performing the type analysis and adapter creation on every call is inherently slow.  A good fix is to cache the result of step 1 (MethodHandles.asType), since step 2 is already reasonably fast.

For most applications, a one-element cache on each individual method handle is a reasonable choice. It has the particular advantage of speeding up invocations of non-varargs bootstrap methods.  To benefit from this, the bootstrap methods themselves need to be uniquified across multiple class files, so this work will also include a cache to benefit commonly-used bootstrap methods, such as JDK 8's LambdaMetafactory.metafactory.

Additional caches could be based on the call site, the call site type, the target type, or the target's MH.form.

Comments
That also includes a fix for an issue which cause JCK test failures with -esa option specified: api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altNullCaller] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntIntUnboxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntInt] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntVoidUnboxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntVoid] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntegerIntegerBoxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntegerInteger] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntegerVoidBoxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosIntegerVoid] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosVoidVoidDflt] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[altPosVoidVoid] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[nullCaller] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntIntUnboxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntInt] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntVoidUnboxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntVoid] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntegerIntegerBoxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntegerInteger] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntegerVoidBoxing] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posIntegerVoid] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posVoidVoidDflt] api/java_lang/invoke/LambdaMetafactory/LambdaMetafactory.html#LambdaMetafactory[posVoidVoid] Due to that reason we do not submit separate CR for these failures, but just label this CR as 'conformance' and 'tck-red'. No specific actions are required from JDK side.
2013-10-04

webrev: http://cr.openjdk.java.net/~jrose/8024761/webrev.00
2013-09-13