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.
Related Reports
Relates :  
Relates :  
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.

i should be applying post loop optimization like vectorized post loop, PostLoopMultiversioning after opaque node removal.

Some interesting benchmarks failed due to infrastructure. Please, re-submit. Or ask for help to run them.

webrev: http://cr.openjdk.java.net/~jcm/8152110/webrev.00/

ILW = Wrong assumptions in C2 loop optimizations may cause crash, no failures observed, disable loop opts = HLM = P3

SQE ok with deferral, since it has no impact on end-users

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

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