Compile::optimize_loops performs PhaseIdealLoop::build_and_optimize()
as long as major_progress() is set or until it reaches the `LoopOptsCount` limit. But loop optimization can get stuck in an infinite loop of performing always the same optimization(s) as happened inJDK-8287284. To detect such cases there used to be an assert, but it was broken and removed in JDK-8284944. In reality we get out of the infinite loop because we hit `LoopOptsCount`. We should introduce a check that detects such cases since it means something gone wrong.
Things to consider:
- Increase the limit of `LoopOptsCount` since there are valid cases (TestMaxLoopOptsCountReached.java) where we could still improve the loop further
- To detect if we are stuck in a cycle it would be good somehow verify that the graph is improving and not just bloating up.
as long as major_progress() is set or until it reaches the `LoopOptsCount` limit. But loop optimization can get stuck in an infinite loop of performing always the same optimization(s) as happened in
Things to consider:
- Increase the limit of `LoopOptsCount` since there are valid cases (TestMaxLoopOptsCountReached.java) where we could still improve the loop further
- To detect if we are stuck in a cycle it would be good somehow verify that the graph is improving and not just bloating up.
- relates to
-
JDK-8284944 assert(cnt++ < 40) failed: infinite cycle in loop optimization
- Resolved
-
JDK-8287284 C2: loop optimization performs split_thru_phi infinitely many times
- Resolved