JDK-8063137 : Never taken branches should be pruned when GWT LambdaForms are shared
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 8u60,9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-11-06
  • Updated: 2017-08-24
  • Resolved: 2017-08-24
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-8074551 - GWT can be marked non-compilable due to deopt count pollution
Relates :  
JDK-8069591 - Customize LambdaForms which are invoked using MH.invoke/invokeExact
Relates :  
JDK-8068915 - C2: uncommon trap w/ Reason_speculate_class_check causes performance regression due to continuous deoptimizations
Description
Latest jdk9-dev:
-Djava.lang.invoke.MethodHandle.USE_LF_EDITOR=false
GbemuBench           89.204        +-8.079     ms

-Djava.lang.invoke.MethodHandle.USE_LF_EDITOR=true
GbemuBench          117.258        +-0.606     ms
Comments
noreg-perf: octane/nashorn
16-04-2015
Non-pruned never taken branches negatively affect peak performance of the following Octane benchmarks: Pessimistic types (-Dnashorn.args=--optimistic-types=false): 3 benchmarks Raytrace: -20%; DeltaBlue: -14%; CodeLoad: -18% Optimistic types (-Dnashorn.args=--optimistic-types=true): 6 benchmarks Gbemu: -30%; Mandreel: -20%; Raytrace: -20%; Richards: -20%; NavierStrokes: -16%; DeltaBlue: -11%; Pessimistic types are the default in 8u40. The fix is out for official review for 9: http://cr.openjdk.java.net/~vlivanov/8063137/webrev.03/ Also, it requires the fix for JDK-8068915, otherwise Gbemu becomes unacceptably slow (up to 15x).
27-01-2015
Case (2) is tracked by JDK-8069591.
21-01-2015
There are 2 sources of regression: (1) Branch frequencies pollution in GuardWithTest. Though BlockInliningWrapper fixed inlining for shared GWT, never-taken branches still suffer when GWTs are shared. (2) LambdaForm sharing worsens inlining when root MethodHandle is not a compile-time constant. When LambdaForms were customized, JIT could produce a single native method for the whole MethodHandle chain down the place where inlining failed. With LambdaForm sharing, it's not possible anymore, so JIT has to generate a native method per every MethodHandle in the chain.
11-12-2014
No, I haven't found the root cause yet. Working on this issue full time.
04-12-2014
Is there any update on this P1 issue?
04-12-2014
The regression is caused by some changes in inlining. Profiler shows bunch of hot compiled lambda forms: java.lang.invoke.LambdaForm$DMH.909470102.invokeVirtual_009_L_L(java.lang.Object, java.lang.Object) java.lang.invoke.LambdaForm$MH.1385309725.guard_000(java.lang.Object, java.lang.Object, java.lang.Object) java.lang.invoke.LambdaForm$MH.788606829.exactInvoker_005(java.lang.Object, java.lang.Object, java.lang.Object) java.lang.invoke.LambdaForm$BMH.913269876.reinvoke_015(java.lang.Object) java.lang.invoke.LambdaForm$MH.1995388907.delegate_003(java.lang.Object, java.lang.Object, java.lang.Object) java.lang.invoke.LambdaForm$DMH.1148856698.invokeStatic_003_LL_L(java.lang.Object, java.lang.Object, java.lang.Object) java.lang.invoke.LambdaForm$MH.1526502386.guardWithCatch_000(java.lang.Object, java.lang.Object, java.lang.Object) java.lang.invoke.LambdaForm$BMH.1573333582.reinvoke_143(java.lang.Object, java.lang.Object)
07-11-2014
ILW=Perf regression, Gbrmu, no workaround planned for release code=HMH=P1
07-11-2014