RFR: 8350579: Remove Template Assertion Predicates belonging to a loop once it is folded away [v3]
Christian Hagedorn
chagedorn at openjdk.org
Tue Mar 25 08:50:08 UTC 2025
> The patch fixes the issue of creating an Initialized Assertion Predicate at a loop X from a Template Assertion Predicate that was originally created for a loop Y. Using the unrelated loop values from loop Y for the Initialized Assertion Predicate will let it fail during runtime and we execute a `halt` instruction. This was originally reported with [JDK-8305428](https://bugs.openjdk.org/browse/JDK-8305428).
>
> Note that most of the line changes are from new tests.
>
> ### The Problem
> There are multiple test cases triggering the same problem. In the following, when referring to "the test case", I'm referring to `testTemplateAssertionPredicateNotRemovedHalt()` which was written from scratch and contains more detailed comments explaining how we end up with executing a `Halt` node in more details.
>
> #### An Inner Loop without Parse Predicates
> The graph in `testTemplateAssertionPredicateNotRemovedHalt()` looks like this after creating `LoopNodes` for the outer `for` and inner `while (true)` loop:
>
> 
>
> We only have Parse Predicates for the outer loop. Why?
>
> Before beautify loop, we have the following region which merges multiple backedges - the one from the `for` loop and the one from the `while (true)` loop:
>
> 
>
> In `IdealLoopTree::merge_many_backedges()`, we notice that the hottest backedge is hot enough such that it is worth to have a separate merge point region for the inner and outer loop. We set everything up and eventually in `IdealLoopTree::split_outer_loop()`, we create a second `LoopNode`.
>
> For this inner `LoopNode`, we cannot set up `Parse Predicates` with the same UCTs as used for the outer loop. It would be incorrect when taking the trap to re-execute the inner and outer loop again while having already executed some of the outer loop's iterations. Thus, we get the graph shape with back-to-back `LoopNodes` as shown above.
>
> #### Predicates from a Folded Loop End up at Another Loop
> As described in the previous section, we have an inner and outer `LoopNode` while the inner does not have Parse Predicates. In a series of events (see test case comments for more details), we first hoist a range check out of the outer loop during Loop Predication with a Template Assertion Predicate. Then, we fold the outer loop away because we find that it is only running for a single iteration and the bac...
Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
- Merge methods
- Merge branch 'master' into JDK-8350579
- Small things
- Fix test comments
- New approach: Marking unrelated Template Assertion Predicates outside of IGVN by storing a reference to the loop it originally was created for.
- Merge branch 'master' into JDK-8350579
- Revert fix completely
- 8350579: Remove Template Assertion Predicates belonging to a
loop once it is folded away during IGVN
-------------
Changes: https://git.openjdk.org/jdk/pull/23823/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23823&range=02
Stats: 700 lines in 9 files changed: 572 ins; 44 del; 84 mod
Patch: https://git.openjdk.org/jdk/pull/23823.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/23823/head:pull/23823
PR: https://git.openjdk.org/jdk/pull/23823
More information about the hotspot-compiler-dev
mailing list