RFR: 8271203: C2: assert(iff->Opcode() == Op_If || iff->Opcode() == Op_CountedLoopEnd || iff->Opcode() == Op_RangeCheck) failed: Check this code when new subtype is added [v3]

Christian Hagedorn chagedorn at openjdk.java.net
Fri Aug 13 13:07:27 UTC 2021


On Fri, 13 Aug 2021 11:41:48 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Hi, I'm trying to fix [JDK-8271203](https://bugs.openjdk.java.net/browse/JDK-8271203). It's reasonable to unswitch LongCountedLoop, so relax it.
>> 
>> ![image](https://user-images.githubusercontent.com/5010047/127302280-0faa90bb-add7-4639-8c63-49668901f267.png)
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   package

> Well, the above CFG is corresponding to the last step(before beautify loops, loop.xml.log ) before crash. I haven't learned about loopopts in C2 yet, it looks like B9 and B19-22 are refer to the same loop(do{...} while ((i2 -= 2) > 0); ), the above CFG looks like:

They probably appear to be very similar on first sight but are not. You can check the `-XX:+TraceLoopOpts` output to see what's going on with your loops. Maybe the loop was already unswitched once and now you have 2 very similar looking loops that correspond to the loop `do{...} while ((i2 -= 2) > 0); )` in the Java code. In general, there is not always a 1:1 relation between a loop in Java code and `LoopNode(s)` in the IR. For example, you could also be dealing with pre/main/post loops for a single Java loop which look very similar.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4920


More information about the hotspot-compiler-dev mailing list