On Tue, 12 May 2026 14:04:34 GMT, Tobias Hartmann <[email protected]> wrote:
>> The problem is that we are pushing casts through InlineTypeNodes without >> checking if their types are even compatible. In dead parts of the graph, >> when a type check wasn't folded yet, the type of the CheckCastPP can be >> completely unrelated to the type of the InlineTypeNode. Pushing the cast >> through leads to an incorrect type being used further below in the graph and >> subsequent failures. >> >> I tried hard to come up with standalone reproducer for this but failed. It >> reproduces reliably with replay compilation though. >> >> Thanks, >> Tobias >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Tobias Hartmann has updated the pull request incrementally with one > additional commit since the last revision: > > Fixed check Thanks for the review Marc! > If I understand well, we just find the inconsistency and leave it there It's not really inconsistency. It's basically "cast A to B if subtype check C succeeds" but C would always fail and A can not be casted to B because they don't have a subtype relation. So the cast would be replaced by TOP and the subtype check would be folded to always false - but only later. > Can we be more active and remove the dead parts of the graph already? Or can > we somehow make sure these nodes are disappearing "soon"? Maybe I'm biased > toward early node killing... These dead data nodes depend on type checks like C in the example above that will be folded during IGVN but that depends on the order in which nodes are processed. In general, and especially with `-XX:+StressIGVN`, that order is basically random, so we have to make sure that all optimizations can handle such dead graphs. In this particular case, we should not assume that checkcast will always "pass" - they might even fail statically if they haven't been processed by IGVN yet. > Unfortunate we don't have a test, but I know the feeling... I wasted hours trying to come up with a targeted test and didn't succeed. It's really hard to get profiling + timing + node processing order right (even with -XX:+StressIGVN etc.). But it did reproduce reliably with replay and in various CI tests at least. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/2423#issuecomment-4432151490
