JDK-8211451 : ~2.5% regression on compression benchmark starting with 12-b11
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows
  • CPU: x86_64
  • Submitted: 2018-10-03
  • Updated: 2022-01-05
  • Resolved: 2018-11-19
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 11 JDK 12
11.0.3Fixed 12 b21Fixed
Related Reports
Duplicate :  
JDK-8214994 - C2 Compiler enters infinite loop and consumes infinite memory until crash
Relates :  
JDK-8209544 - AES encrypt performance regression in jdk11b11
Description
From internal testing.
Comments
Fix Request This bug fixes a performance regression introduced by JDK-8209544 (for which I requested backport approval) and fixes a hang in c2 (JDK-8214994) The fix tweaks c2 code generation. It was pushed in 12 a month and there was no regression that I'm aware of. Patch applies cleanly.
17-12-2018
This patch (accidentally) fixed JDK-8214994 and should therefore be backported to JDK 11. Raising priority and adding 11-bp label.
14-12-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/61241fc2217a User: roland Date: 2018-11-19 13:39:10 +0000
19-11-2018
Testing passed clean.
09-10-2018
[~kvn] http://cr.openjdk.java.net/~roland/8211451/webrev.00/
09-10-2018
[~roland] Can you add link to final webrev here to use for testing?
08-10-2018
[~ecaspole] Thanks for verify the fix. Any update on the extensive testing?
08-10-2018
[~roland] The patch fixes the performance regression on Compress. I have not yet run all the normal benchmarks on it - I will try it overnight on the whole suite.
04-10-2018
[~roland] Thanks I will try it today.
04-10-2018
The Compressor::output() method has a loop for which the exit condition is transformed by code added for 8209544: if ((_test._test == BoolTest::eq || _test._test == BoolTest::ne) && cop == Op_CmpI && cmp1_op == Op_AddI && cmp1->in(2) != NULL && phase->type(cmp1->in(2))->isa_int() && phase->type(cmp1->in(2))->is_int()->is_con() && cmp2_type == TypeInt::ZERO && !is_counted_loop_cmp(cmp) // modifying the exit test of a counted loop messes the counted loop shape ) { const TypeInt* cmp1_in2 = phase->type(cmp1->in(2))->is_int(); Node *ncmp = phase->transform( new CmpINode(cmp1->in(1),phase->intcon(-cmp1_in2->_hi))); return new BoolNode( ncmp, _test._test ); } That loop is then not transformed into a counted loop because the following test in PhaseIdealLoop::is_counted_loop(): if (phi_incr != NULL) { // check if there is a possiblity of IV overflowing after the first increment if (stride_con > 0) { if (init_t->_hi > max_jint - stride_con) { return false; } } else { if (init_t->_lo < min_jint - stride_con) { return false; } } } Possible fix: diff --git a/src/hotspot/share/opto/loopnode.cpp b/src/hotspot/share/opto/loopnode.cpp --- a/src/hotspot/share/opto/loopnode.cpp +++ b/src/hotspot/share/opto/loopnode.cpp @@ -540,7 +540,7 @@ return false; // cyclic loop or this loop trips only once } - if (phi_incr != NULL) { + if (phi_incr != NULL && bt != BoolTest::ne) { // check if there is a possiblity of IV overflowing after the first increment if (stride_con > 0) { if (init_t->_hi > max_jint - stride_con) {
04-10-2018
Roland, could you please have a look? ILW = Small performance regression, single benchmark, no workaround = MMH = P3
04-10-2018
Here's the promo trend for Windows showing the same drop in performance: http://aurora.se.oracle.com/performance/reporting/batch-report/details/promo.12-b11?type=Windows%20x64%20Server&series=SPECjvm2008-Compress-G1&ref=promo.10-b46.13%20to%20promo.12-b13&compareTo=previous
03-10-2018