RFR: 8359235: C1 compilation fails with "assert(is_single_stack() && !is_virtual()) failed: type check" [v3]
Guanqiang Han
ghan at openjdk.org
Sun Jul 27 15:58:52 UTC 2025
On Fri, 25 Jul 2025 14:39:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:
> Thanks for looking into this!
>
> When I run your test with `java -Xcomp -XX:TieredStopAtLevel=1 -XX:C1MaxInlineSize=200 Test.java` we still crash when compiling `java.lang.invoke.LambdaFormEditor::putInCache` and if I restrict compilation to your test method via `-XX:CompileCommand=compileonly,Test::*`, the issue does not reproduce anymore. Could you please add a targeted regression test for this issue?
@TobiHartmann Thanks for the feedback! I think there might be a bit of a misunderstanding.
The original test program I provided is actually meant to reproduce the issue when run with: "java -Xcomp -XX:TieredStopAtLevel=1 -XX:C1MaxInlineSize=200 Test.java",it usually takes about 10 minutes to trigger the crash. Using -XX:CompileCommand=compileonly,Test::* won’t reproduce the issue because it compiles only a small subset of methods, which doesn’t put enough pressure on the register allocator to cause the spill (stack2reg can not be called ). Let’s forget about the previous test — I’ve redesigned a new one and already committed it. Feel free to give it a try when you have time!
> +1 to what Dean suggested. I think other intrinsics are affected by this as well though, for example:
>
> https://github.com/openjdk/jdk/blob/b1fa1ecc988fb07f191892a459625c2c8f2de3b5/src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp#L953-L962
>
> Also, what about other platforms than x86?
@TobiHartmann Other methods such as do_update_CRC32 may have similar issues, but they are harder to reproduce. Fortunately, other architectures have not implemented do_vectorizedMismatch.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26462#issuecomment-3124508002
More information about the hotspot-compiler-dev
mailing list