Please review this change for a change to the JSR 292 implementation: http://cr.openjdk.java.net/~jrose/8024761/webrev.00/
Bug 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. Thanks, — John P.S. Since this is an implementation change oriented toward performance, the review request is to mlvm-dev and hotspot-compiler-dev. Changes which are oriented toward functionality will go to mlvm-dev and core-libs-dev. _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
