RFR: 8354767: Test crashed: assert(increase < max_live_nodes_increase_per_iteration) failed: excessive live node increase in single iteration of IGVN: 4470 (should be at most 4000)

[Daniel Lundén]

On Wed, 7 May 2025 11:25:42 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> @dafedafe
>>> Looks good to me. Just a quick (curiosity) question: why did you choose to multiply by 3 and not, for instance, doubling the current max amount (i.e. x 4)?
>> 
>> Thanks for the review! We'd like to keep this bound as small as possible so that we do not get a too conservative IGVN node count bailout. But, I guess using 4 instead of 3 doesn't really matter in practice and perhaps it looks cleaner to use a power of 2.
>> 
>> @robcasloz @eme64
>>> If we cannot bound the amount of nodes that can be created by PhiNode::Ideal, wouldn't it be more robust to simply disable the single-iteration node increase assertion for PhiNode? Otherwise there is the risk that we encounter the failure again with a slightly larger test case. Alternatively, if we could (?) derive a tighter bound for PhiNode (e.g. based on its number of inputs, number of memory slices for memory phis, etc.) we could try to compute it and use it in the assertion.
>> 
>>> @robcasloz @dlunde Yes, such an exception may help us keep tight bounds on most nodes. And maybe we can even quantify more precisely how many nodes we expect to be created by PhiNode::Ideal. Maybe it is somehow linear in its inputs?
>> 
>> The issue with weakening the per-iteration assertion in special cases is that we _must_ ensure that we do not grow by more than `max_live_nodes_increase_per_iteration` in a single iteration. Below is my failure analysis for [JDK-8351833](https://bugs.openjdk.org/browse/JDK-8351833) which describes the issue.
>> 
>>> After the changes for 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.
>> 
>> I guess we could just remove [the assert during node creation](https://github.com/openjdk/jdk/blob/50554fa1982f042fb1d7b6c8a16334b97b31bb63/src/hotspot/share/opto/nod...
>
>> The issue with weakening the per-iteration assertion in special cases is that we _must_ ensure that we do not grow by more than `max_live_nodes_increase_per_iteration` in a single iteration. Below is my failure analysis for [JDK-8351833](https://bugs.openjdk.org/browse/JDK-8351833) which describes the issue.
> 
> Fair enough, thanks for the explanation.

Thanks for the review @robcasloz!

@eme64 
> @dlunde Ok, then let's declare this as a "quickfix", and file a follow-up RFE. Maybe it should also be declared a lower-priority bug?

Sounds good to me. Yes, definitely lower priority for now. We do not even know if the transformation is expected or not, although I agree it looks suspicious.

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

PR Comment: https://git.openjdk.org/jdk/pull/24960#issuecomment-2858382888