RFR: 8351833: Unexpected increase in live nodes when splitting Phis through MergeMems in PhiNode::Ideal [v2]

[Daniel Lundén]

> 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 ...

Daniel Lundén has updated the pull request incrementally with one additional commit since the last revision:

  Clean up code related to eager transformation and rename itergvn to igvn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24325/files
  - new: https://git.openjdk.org/jdk/pull/24325/files/eabf1c0c..76240722

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24325&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24325&range=00-01

  Stats: 11 lines in 3 files changed: 0 ins; 9 del; 2 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