Details
-
Enhancement
-
Resolution: Fixed
-
P3
-
8
-
b112
-
Not verified
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.
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.
Attachments
Issue Links
- duplicates
-
JDK-8024630 Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance
- Closed
- relates to
-
JDK-8016582 JSR 292 generic invoke needs to be fast
- Open
-
JDK-8024630 Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance
- Closed
-
JDK-8025107 java/lang/invoke/RevealDirectTest.java failing
- Resolved
-
JDK-8026941 [TESTBUG] java.lang.ClassNotFoundException: java.lang.invoke.InvokeGeneric
- Resolved
-
JDK-8026288 Performance regression in MethodHandles.invoker
- Closed
(1 relates to)