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.
8u60Fixed 9 b52Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Latest jdk9-dev:
GbemuBench           89.204        +-8.079     ms

GbemuBench          117.258        +-0.606     ms

noreg-perf: octane/nashorn

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).

Case (2) is tracked by JDK-8069591.

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.

No, I haven't found the root cause yet. Working on this issue full time.

Is there any update on this P1 issue?

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)

ILW=Perf regression, Gbrmu, no workaround planned for release code=HMH=P1