JDK-8152110 : Stabilize C2 loop optimizations
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-03-17
  • Updated: 2022-03-09
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8148754 - C2 loop unrolling fails due to unexpected graph shape
Relates :  
JDK-8144487 - PhaseIdealLoop::build_and_optimize() must restore major_progress flag if skip_loop_opts is true
Description
To perform some loop optimizations, the C2 compiler requires well-defined graph shapes at certain places. To preserve these graphs during the loop optimization process, C2 hides some nodes behind "opaque" nodes (e.g., Opaque[1-3]). Also, C2 assumes that opaque nodes are removed only after all loop optimizations have finished.

C2's assumption regarding the removal of opaque nodes is wrong. Loop nodes are removed after major_progress is set to false, because major_progress is assumed to indicate that no more loop optimizations will be performed.

Unfortunately, major_progress can reset to true after some opaque nodes have been removed (see, e.g., Node::remove_useless_bool()). That results in inappropriate graph shapes showing up and C2 crashing as a result (see, e.g., JDK-8148754).

The issue related to the inconsistent usage of major_progress has been described and partially addressed by JDK-8144487. However, as JDK-8148754 shows, the usage of major_progress is inconsistent and more work remains to be done.
Comments
i should be applying post loop optimization like vectorized post loop, PostLoopMultiversioning after opaque node removal.
21-12-2017
Some interesting benchmarks failed due to infrastructure. Please, re-submit. Or ask for help to run them.
13-12-2017
webrev: http://cr.openjdk.java.net/~jcm/8152110/webrev.00/
11-12-2017
ILW = Wrong assumptions in C2 loop optimizations may cause crash, no failures observed, disable loop opts = HLM = P3
20-02-2017
SQE ok with deferral, since it has no impact on end-users
17-06-2016
9-defer-request: Currently, loop optimizations implemented in the C2 compiler don't conform to the convention using opaque nodes (i.e., that opaque nodes are removed only in the last stage of loop optimizations). Currently, opaque nodes are removed earlier that can result in failures. Currently, all such failures have been fixed, but on the long term, it is important that we fix C2 to adhere to the convention using opaque nodes (so that possible failures are avoided in the future).
15-06-2016
Here is a prototype implementation that solves the problem: http://cr.openjdk.java.net/~zmajo/code/8148754/webrev/ I've also attached the code to the bug description (8148754-work.patch). Unfortunately, the prototype result in 3-5% performance regression for SPECjvm2008-MonteCarlo-G1. So the main task with this bug is to improve the prototype so that the regression is eliminated. Also, the code of the prototype, although correct, must be somewhat improved to reach production quality. For the discussion that resulted in the the prototype please see the the hotspot-compiler-dev mailing list: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021353.html http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/021967.html
17-03-2016