RFR: 8356761: IGV: dump escape analysis information

Christian Hagedorn chagedorn at openjdk.org
Wed Nov 5 14:10:00 UTC 2025


On Thu, 30 Oct 2025 13:49:44 GMT, Anton Seoane Ampudia <aseoane at openjdk.org> wrote:

> This PR introduces new IGV dumps, property fields and filters related to escape analysis information.
> 
> The C2 escape analysis algorithm is carried out in six primary steps, of which many have interesting sub-steps (e.g. `split_unique_types`) or present an iterative nature where access to intermediate results can aid debugging and analysis. Additionally, escape analysis relies on an "intermediate structure" called the _connection graph_, which is also particularly valuable for deeper investigations.
> 
> With this changeset, escape analysis information is now dumped at key points throughout the algorithm, with a degree of granularity (from only the basic steps to in-detail iterative dumping). The dumps include several property fields, such as:
> 
> - Node escape “level”.
> - Scalar replaceability.
> - Node type within the connection graph (per [C2 Escape Analysis connection graph](https://wiki.openjdk.org/display/HotSpot/EscapeAnalysis)).
> 
> This is achieved by passing the `ConnectionGraph` in use to the `IdealGraphPrinter` during escape analysis, so that these properties can be dumped. After escape analysis, remaining interesting information that is left until macro elimination (and consequent elimination of non-escaping, replaceable allocations) is also dumped.
> 
> Additionally, two filters are provided: one for displaying the connection node type in the IGV node box, and another one for color-scaling nodes based on their escaping/scalar status.
> 
> **Testing:** passes tiers 1-3, manual testing in IGV

Nice improvement! I have not reviewed this PR, yet, but I just want to raise a general concern that our model of having different `PrintIdealGraphLevel` values might not fit anymore for all the different concepts (different loop opts, IGVN steps, Superword steps, parsing steps and now EA steps etc.). Maybe the time has come to use a different solution to allow some better filtering for different needs. It should not per se block this PR but could be a justification to actually tackle this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28060#issuecomment-3491408399


More information about the hotspot-compiler-dev mailing list