Bug ID: JDK-8313717 C2: assert(false) failed: infinite loop in PhaseIterGVN::optimize

Versions (Unresolved/Resolved/Fixed)

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 22
22Unresolved

Found this while writing regression tests for JDK-8310190.

Reporduce like this:

java -Xcomp -XX:-TieredCompilation -XX:CompileCommand=compileonly,Test2::test -XX:CompileCommand=printcompilation,Test2::test* -XX:+TraceNewVectors -XX:+TraceSuperWord -XX:+TraceLoopOpts -XX:LoopUnrollLimit=10000  Test2.java


# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/oracle-work/jdk-fork7/open/src/hotspot/share/opto/phaseX.cpp:1004), pid=590714, tid=590727
#  assert(false) failed: infinite loop in PhaseIterGVN::optimize
#
# JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-internal-2023-07-19-1629373.emanuel...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-internal-2023-07-19-1629373.emanuel..., compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x150505b]  PhaseIterGVN::dump_infinite_loop_info(Node*, char const*) [clone .part.0]+0x2b
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /oracle-work/jdk-fork7/build/linux-x64-slowdebug/jdk/bin/core.590714)
#
# An error report file with more information is saved as:
# /oracle-work/jdk-fork7/build/linux-x64-slowdebug/jdk/bin/hs_err_pid590714.log
#
# Compiler replay data is saved as:
# /oracle-work/jdk-fork7/build/linux-x64-slowdebug/jdk/bin/replay_pid590714.log

ILW = Infinite loop in IGVN - bailout in product, edge case?, no workaround = MLH = P4

04-08-2023

If I recall correctly, IGV worklist is not queue or stack - it is more complicated and nodes could processed not in the order you put it on or end up in a place on list were you would expect them be. This is again the issue that data/memory nodes processing does not match control flow elimination. I think we have umbrella RFE for that.

04-08-2023

[~kvn] I just ran into this: https://github.com/openjdk/jdk/commit/78034a3d3b44c416689d6714d79c5b3c23c9de40 https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2011-December/006804.html https://bugs.openjdk.org/browse/JDK-7117282 You decided to put memnodes back on the worklist, if their input memnode is still on the list. This means that we process memnodes from input to output. If we have a long chain, it is eventually processed all the way down. But: if the chain was in the reverse order in the worklist, then we only process a single node per traversal of the worklist. If I am right this could lead to quadratic runtime. If the worklist was randomly shuffled it would take O(n log n) in expectation. I'm getting a "infinite loop" assert because the number of IGVN iterations exceeds the limit. I have a case where I have lots of memops, then unroll, partially superword. Lots of scalars still linger around. I set -XX:LoopUnrollLimit=10000 so we super-unroll the superworded loop. And that leads to massive amounts of nodes. I get a memops chain of over 7k nodes (1 phi and lots of scalar and vector stores). When the assert triggers the nodes below the phi are not on the worklist, but the nodes further down the list are all on the worklist. Not yet sure why the memops ended up in that bad order on the worklist.

03-08-2023

Blocks :	JDK-8310190 - C2 SuperWord: AlignVector is broken, generates misaligned packs
Relates :	JDK-7117282 - Tiered: assert(base == NULL \|\| t_adr->isa_rawptr() \|\| !phase->type(base)->higher_equal(TypePtr: