JDK-8069591 : Customize LambdaForms which are invoked using MH.invoke/invokeExact
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 8u60,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-01-21
  • Updated: 2017-08-24
  • Resolved: 2015-01-29
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 JDK 9
8u60Fixed 9 b52Fixed
Related Reports
Relates :  
JDK-8046703 - JEP 210: LambdaForm Reduction and Caching
Relates :  
JDK-8063137 - Never taken branches should be pruned when GWT LambdaForms are shared
Description
Overhead of non-inlined MH.invoke/invokeExact calls significantly increased with LambdaForm sharing.
The cause is JIT compiler can't produce a single nmethod for the whole MethodHandle chain underneath, so the execution is spread around numerous nmethods (1 per each MethodHandle in the chain). 

ILW = HLH = P2
I = H: performance regression (significant, in some situations)
L = L: only MH.invoke/invokeExact calls with non-constant receiver are affected
W = H: none
Comments
noreg-perf: octane/nashorn
16-04-2015
8u40-defer-request: The likelihood of the problem is quite low: it only affects MethodHandle.invokeExact()/invoke() calls when receiver MethodHandle is not a constant for JIT. Inlining doesn't work in that case, but w/o customization (after LambdaForm sharing) non-inlined MethodHandle becomes more expensive. The problem severely affects only Gbemu w/ optimistic types (-30% peak performance). Since optimistic types are turned OFF by default on 8u40, I'd recommend to defer the bug to 8u60.
27-01-2015
Proposed fix: http://cr.openjdk.java.net/~vlivanov/8069591/webrev.02/
27-01-2015
It causes -30% regression in peak performance on Gbemu w/ optimistic types (-Dnashorn.args=--optimistic-types=true, turned OFF by default in 8u40).
27-01-2015