JDK-8068915 : C2: uncommon trap w/ Reason_speculate_class_check causes performance regression due to continuous deoptimizations
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u60,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-01-13
  • Updated: 2019-01-31
  • 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-8218163 - C2: Continuous deoptimization w/ Reason_speculate_class_check and Action_none
Relates :  
JDK-8063137 - Never taken branches should be pruned when GWT LambdaForms are shared
Description
Some of Nashorn subbenchmarks can suffer a lot when an uncommon trap w/ Reason_speculate_class_check sometimes settles with Action_none after too many traps occured. It causes continuous deoptimizations and performance regresses a lot (up to 50x). 

ILW = HLH = P2
I = H: severe performance regression on Nashorn
L = L: requires very specific race between nmethod deoptimizations and recompilation; Nashorn & other JSR292 users are affected   
W = H: none
Comments
noreg-perf: octane/nashorn
16-04-2015
8u40-defer-request: The problem is observed only on PdfJS w/ optimistic types. 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/8068915/webrev.01/
27-01-2015
It also severely affects PdfJS in 8u40 (2x-4x slow down in peak performance) w/ optimistic types (-Dnashorn.args=--optimistic-types=true, turned OFF by default in 8u40).
27-01-2015
It contributes to the peak performance regression seen on Octane/Nashorn w/ LambdaForm sharing (JDK-8063137).
13-01-2015
Possible fix: @@ -2786,7 +2787,9 @@ { PreserveJVMState pjvms(this); set_control(slow_ctl); uncommon_trap(reason, - Deoptimization::Action_maybe_recompile); + Deoptimization::Action_maybe_recompile, + /*klass=*/NULL, /*reason_string=*/NULL, + /*must_throw=*/false, /*keep_exact_action=*/true); } if (safe_for_replace) { replace_in_map(not_null_obj, exact_obj); @@ -2835,7 +2838,9 @@ PreserveJVMState pjvms(this); set_control(slow_ctl); uncommon_trap(class_reason, - Deoptimization::Action_maybe_recompile); + Deoptimization::Action_maybe_recompile, + /*klass=*/NULL, /*reason_string=*/NULL, + /*must_throw=*/false, /*keep_exact_action=*/true); } replace_in_map(not_null_obj, exact_obj); obj = exact_obj;
13-01-2015
Speculative traps already have fallback case when too many traps occur. The logic in uncommon_trap shouldn't voluntary switch to Action_none once too_many_recompiles is achieved.
13-01-2015