RFR: 8350864: C2: verify structural invariants of the Ideal graph [v3]

Marc Chevalier mchevalier at openjdk.org
Thu Sep 4 09:04:43 UTC 2025


On Mon, 25 Aug 2025 13:50:24 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Benoît's comments
>
> src/hotspot/share/opto/graphInvariants.hpp line 37:
> 
>> 35:   static constexpr int OutputStep = -1;
>> 36: 
>> 37:   struct LazyReachableCFGNodes {
> 
> You could add a comment here. What I was surprised by: that you do a whole graph traversal the first time we call `is_node_dead`. I thought you would just visit a subgraph every time, and fill out the `live_nodes` gradually.
> 
> You could also give an explanation why it needs to be lazy. Is it possible that we never call `is_node_dead`?

I don't think it makes much sense to visit a subgraph: I want a proof a node is dead. I could climb from the node, trying to reach the root, and traverse a lot of things, that I can't say yet if they are dead or not. Once I saturated or reached the root, I can say for those, but it seems that the logic is more tricky: I would have 3 state per node: dead, alive, not decided yet. I don't think it's worth the complexity.

Also, let's not exaggerate: it's a traversal only of the control sub-graph, not the whole graph. It is much smaller.

I think I give an explanation in the comment of `LocalGraphInvariant::check`:
> The parameter [live_nodes] is used to share the lazily computed set of CFG nodes reachable from root. This is because some checks don't apply to dead code, suppress their error if a violation is detected in dead code.

So we would call `is_node_dead` only if there is a violation of a check that we should suppress in dead code. If there is no violation of such a check (no violation at all, or only of checks that we still want to see from dead code), we won't call `is_node_dead`. I'll improve the comment and point to there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26362#discussion_r2321348168


More information about the hotspot-compiler-dev mailing list