RFR: 8351833: Unexpected increase in live nodes when splitting Phis through MergeMems in PhiNode::Ideal
Daniel Lundén
dlunden at openjdk.org
Mon Mar 31 12:31:47 UTC 2025
After the changes for [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393), we apply a Phi idealization, involving splitting Phis through MergeMems, a lot more frequently. This idealization internally applies further idealizations for new Phi nodes generated during the idealization. In certain cases, these internal idealizations result in a large increase of live nodes within a single iteration of the main IGVN loop in `PhaseIterGVN::optimize`. In particular, when we are close to the `MaxNodeLimit` (80 000 by default), it can happen that we go from below `MaxNodeLimit - NodeLimitFudgeFactor * 2` (= 76 000 by default) to more than 80 000 nodes in a single iteration. In such cases, the node count bailout at the top of the `PhaseIterGVN::optimize` loop does not trigger as expected and we instead crash at an assert in node creation as we surpass `MaxNodeLimit` nodes.
### Changeset
Changes:
- Do not immediately transform new Phi nodes after splitting Phis through MergeMems. The Phi nodes are put on the IGVN worklist and are transformed later on in any case.
- Add an assert in the `PhaseIterGVN::optimize` loop that ensures we never increase the live node count with more than `NodeLimitFudgeFactor * 2` in a single loop iteration. This assert allows us to catch the issue earlier and much more frequently during IGVN.
- Add a new regression test `TestSplitPhiThroughMergeMem.java`. The new assert above triggers the issue in a large number of existing tests already, but I added this new test as well for good measure.
### Testing
- [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/14124983489)
- `tier1` to `tier4` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.
- Performance testing
- DaCapo 23, Renaissance, SPECjbb 2005, and SPECjvm 2008 on Windows x64, Linux x64, macOS x64, and macOS aarch64. No statistically significant improvements nor regressions.
- Compilation time benchmarking for DaCapo 23. No statistically significant improvements nor regressions.
### Additional issue investigation
For the particular failure reported as part of this issue, the additional Phi idealizations after [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393) cause a dramatic local increase in the number of nodes during IGVN compared to before. Therefore, it is justified to further investigate if this increase in live nodes is, in general, an issue in itself. In the below, I consider and refer to three versions of the JVM:
- Before the fix for [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393) ("baseline")
- After the fix for [JDK-8333393](https://bugs.openjdk.org/browse/JDK-8333393) ("target-old")
- After the fix in this PR ("target")
First, consider the number of live nodes and the IGVN worklist size during the particular IGVN run that resulted in this issue. Orange is the number of live nodes and blue the worklist size, and I increased `MaxNodeLimit` to ensure IGVN runs to completion.
Note that, for "baseline", both the live nodes and worklist size decrease more or less monotonically and the IGVN run finishes quickly. For both "target-old" and "target", the additional Phi idealizations result in dramatic local increases of live nodes, and the IGVN runs have an order of magnitude more iterations compared to "baseline". However, after the IGVN runs, the number of nodes is still reasonable.
To investigate if the local live node increases are an issue in general, I ran the DaCapo 23 benchmark suite and collected three statistics for each IGVN run:
- max live nodes,
- max live node increment (in a single IGVN step), and
- max IGVN worklist size.
Below are the results, shown with violin plots. The endpoints are the maximum values and the midpoints are the arithmetic means. The shaded areas approximate the distribution of the statistics (over all IGVN runs).
In particular, note the sharp difference between "target-old" and the other two versions for "Max live node increment". This changeset addresses this difference (i.e., the difference between "target-old" and "target").
Overall, the distributions and extrema for "target" and "baseline" are comparable. **This motivates that the dramatic live node increase seen in this issue is an edge case and is not a problem in general.** Additionally, there were 0 IGVN node count bailouts across all versions for DaCapo. I also ran Renaissance, SPECjvm, and SPECjbb to check if there were any differences in bailout counts (total, not only IGVN node count bailouts):
- "baseline": 252 bailouts
- "target-old": 255 bailouts
- "target": 253 bailouts
It could be worth investigating the 1-bailout difference between "baseline" and "target", but the difference could also likely be attributed to noise.
-------------
Commit messages:
- First version
Changes: https://git.openjdk.org/jdk/pull/24325/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24325&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8351833
Stats: 93 lines in 4 files changed: 87 ins; 1 del; 5 mod
Patch: https://git.openjdk.org/jdk/pull/24325.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24325/head:pull/24325
PR: https://git.openjdk.org/jdk/pull/24325
More information about the hotspot-dev
mailing list