JDK-8235984 : C2: assert(out->in(PhiNode::Region) == head || out->in(PhiNode::Region) == slow_head) failed: phi must be either part of the slow or the fast loop
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,14,15
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-12-16
  • Updated: 2022-06-27
  • Resolved: 2020-01-07
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 13 JDK 14 JDK 15
11.0.8-oracleFixed 13.0.4Fixed 14 b31Fixed 15Fixed
Related Reports
Duplicate :  
JDK-8236412 - SEGV in Node::uncast with Lucene
Relates :  
JDK-8236722 - Extend loop unswitching to handle loop predicates with a control dependency to partially peeled statements
Relates :  
JDK-8233033 - C2 produces wrong result while unswitching a loop due to lost control dependencies
Description
#  Internal Error (open/src/hotspot/share/opto/loopUnswitch.cpp:343), pid=11734, tid=11763
#  assert(out->in(PhiNode::Region) == head || out->in(PhiNode::Region) == slow_head) failed: phi must be either part of the slow or the fast loop

# JRE version: Java(TM) SE Runtime Environment (14.0+28) (fastdebug build 14-ea+28-1351)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-ea+28-1351, mixed mode, tiered, parallel gc, linux-amd64)
Comments
Fix request (13u): The original change applies cleanly, passes tier1 and tier2 tests.
03-06-2020
8u backport: this is follow up to JDK-8233033 that's not backported at this point
30-03-2020
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.8-oracle. Applies clean.
17-03-2020
URL: https://hg.openjdk.java.net/jdk/jdk14/rev/b567c4b48777 User: thartmann Date: 2020-01-07 16:29:19 +0000
07-01-2020
The problem: The original fix for JDK-8233033 [1] assumed that partially peeled statements always have a dependency inside the loop to be unswitched (i.e. when following their outputs eventually a phi node is hit belonging to either the slow or the fast loop). However, that is not always the case. As a result the assert was hit. I suggest the following options: Option a) http://cr.openjdk.java.net/~chagedorn/8235984/webrev.a.00/ We explicitly check the assumption that partially peeled statements have a dependency in the loop to be unswitched at the start of loop unswitching. If that is not the case, we bailout. This means we first check if there are loop predicates for the loop to be unswitched and if they have an additional control dependency to partially peeled statements (outcnt > 1). We could then file an RFE for JDK-15 to handle this missing case properly and remove the bailout. Option b) http://cr.openjdk.java.net/~chagedorn/8235984/webrev.b.00/ We only check if there are loop predicates for the loop to be unswitched and if they have an additional control dependency to partially peeled statements (outcnt > 1). If that's the case we bailout without having the fix from JDK-8233033. We could then file an RFE for JDK-15 to properly handle partially peeled statements all together (kinda a REDO of the fix for JDK-8233033). Option c) Trying to fix the missing cases from JDK-8233033 for JDK-14 without a bailout. I've tried to come up with a fix (option c) last week but without success so far. The idea was to also clone the partially peeled statements without a dependency in the loop to be unswitched, change their control input to the correct cloned predicates and then add a phi node on each loop exit, where we merge the slow and fast loop, to select the correct value. However, this has not worked properly, yet and also involves a higher risk due to its complexity. I think we should not target that option for JDK-14 but do it for JDK-15 in an RFE. Thus, I'd opt for either option a) or b). I tested Tier 1-7 for the complete bailout b) and Tier 1-8 for the "conditioned" bailout a). Both look fine. I also ran some standard benchmarks comparing a) and b) to a baseline where I excluded the fix for JDK-8233033 (without bailing out and trying to fix the problem). I could not see any difference in performance. And therefore it suggests to go with the low risk option b) for JDK-14 and do the entire fix in an RFE for JDK-15.
23-12-2019
This has now also been reported by the Lucene team (JDK-8236412).
20-12-2019
ILW = Assert during loop unswitching (regression in JDK 14), with Lucene at tier 7, disable loop unswitching = HMM = P2
16-12-2019