RFR: 8361608: C2: assert(opaq->outcnt() == 1 && opaq->in(1) == limit) failed [v2]

Christian Hagedorn chagedorn at openjdk.org
Tue Oct 7 11:40:48 UTC 2025


On Mon, 6 Oct 2025 14:32:55 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> > We hit this assert in the past due to bugs ([link](https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22opaq-%3Eoutcnt()%20%3D%3D%201%5C%22%22)).
> 
> I might misunderstand, but some of these issues (for instance [JDK-8298353](https://bugs.openjdk.org/browse/JDK-8298353) and backport, duplicate...) seems purely to be hitting the assert, and I don't always see another problem. 

I think here we hit the same assert and actually fixed a bug with split If here: https://github.com/openjdk/jdk/pull/11391

> I wonder if it has been years we are trying to make the assert truer while it doesn't really need to hold (and indeed, it has no reason to hold in general).

But I think it's a key property that the  zero trip guard share the same limit as the loop exit test, otherwise, something is off. So, it should hold in general which the assert tries to verify. We now seem to have found a special case where useless phi are violating the property. If we remove the assert and introduce a bug later which violates this property, we might not notice it anymore.

It now really depends on how complex/impactful a solution that keeps the assert would be. I guess it will be a trade-off.

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

PR Comment: https://git.openjdk.org/jdk/pull/27586#issuecomment-3376497278


More information about the hotspot-compiler-dev mailing list