[9, 8u40] RFR (XS): 8068915: uncommon trap w/ Reason_speculate_class_check causes performance regression due to continuous deoptimizations

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Mon Jan 19 19:27:31 UTC 2015


Roland, thanks for the feedback!

>> The fix is to (1) forbid changing uncommon trap action under the hood, and (2) consult Compile::too_many_recompiles when adding a speculative guard.
>
> I’m not sure I understand what code (1) above is referring to in your webrev.
The fix is based on 8063137 which I've sent for review earlier.
GraphKit::uncommon_trap_exact [1] delegates to 
GraphKit::uncommon_trap(..., /*keep_exact_action=*/true). 
keep_exact_action guards the logic which rewrites the action.

> Also, why is the problem restricted to speculative traps? Wouldn’t the same checks be required for non speculative traps as well?
Other trap types could be affected as well, but speculative traps and 
unstable_if are the main source of action transitions. My experiments on 
Octane show that all cases when action substitution happens have one of 
these trap reason.

With this change I wanted to address speculative traps case. I'll 
experiment with making unstable_if traps exact as well and get back to 
you with updated webrev.

I'd prefer to change the default for keep_exact_action to true (and fix 
only the case mentioned in GraphKit::uncommon_trap [3]), but since I 
consider backporting the fix into 8u40, I want to keep it very focused.

Best regards,
Vladimir Ivanov

[1] 
http://cr.openjdk.java.net/~vlivanov/8063137/webrev.00/hotspot/src/share/vm/opto/graphKit.hpp.udiff.html
[2] http://cr.openjdk.java.net/~vlivanov/8063137
[3] 
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/share/vm/opto/graphKit.cpp#l1986


More information about the hotspot-compiler-dev mailing list