RFR: 8359235: C1 compilation fails with "assert(is_single_stack() && !is_virtual()) failed: type check"

[Guanqiang Han]

I'm able to consistently reproduce the problem using the following command line and test program ：

java -Xcomp -XX:TieredStopAtLevel=1 -XX:C1MaxInlineSize=200 Test.java

import java.util.Arrays;
public class Test{
      public static void main(String[] args) {
        System.out.println("begin"); 
        byte[] arr1 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
        byte[] arr2 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
        System.out.println(Arrays.equals(arr1, arr2)); 
        System.out.println("end");
    }
}

>From my analysis, the root cause appears to be a mismatch in operand handling between T_ADDRESS and T_LONG in LIR_Assembler::stack2reg, especially when the source is marked as double stack (e.g., T_LONG) and the destination as single CPU register (e.g., T_ADDRESS), leading to assertion failures like assert(is_single_stack())(because T_LONG is double_size).

In the test program above , the call chain is: Arrays.equals → ArraysSupport.vectorizedMismatch → LIRGenerator::do_vectorizedMismatch
Within the do_vectorizedMismatch() method, a move instruction constructs an LIR_Op1. During LIR to machine code generation, LIR_Assembler::stack2reg was called.

In this case, the src operand has type T_LONG and the dst operand has type T_ADDRESS. This combination triggers an assert in stack2reg, due to a mismatch between the stack slot type and register type handling.

Importantly, this path ( LIR_Assembler::stack2reg was called )  is only taken when src is forced onto the stack. To reliably trigger this condition, the test is run with the -Xcomp option to force compilation and increase register pressure. 

A reference to the relevant code paths is provided below :
<img width="1260" height="720" alt="image1" src="https://github.com/user-attachments/assets/d0d6a8e2-4316-4475-86a6-58f5f274682c" />
<img width="598" height="206" alt="image2" src="https://github.com/user-attachments/assets/90d1bcdd-c9fa-4598-b8a6-101101caad9c" />

On 64-bit platforms, although T_ADDRESS is classified as single_size, it is in fact 64 bits wide ,represent a single 64-bit general-purpose register  and  it can hold a T_LONG value, which is also 64 bits.

However, T_LONG is defined as double_size, requiring two local variable slots or a pair of registers in the JVM's abstract model. This mismatch stems from the fact that T_ADDRESS is platform-dependent: it's 32 bits on 32-bit platforms, and 64 bits on 64-bit platforms — yet its size classification remains single_size regardless.

This classification leads to mismatches in internal logic, such as when T_LONG values are moved into a T_ADDRESS-typed destination on 64-bit platforms, despite both being 64-bit wide.

I believe this discrepancy is largely historical, originating from the need to support both 32-bit and 64-bit architectures. Given that most modern platforms are 64-bit, I propose to simplify and clarify this handling by allowing T_ADDRESS to accept T_LONG data during move operations when targeting 64-bit platforms.

So i suggest relaxing the type checks for platform-dependent types such as T_ADDRESS and T_METADATA.

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

Commit messages:
 - 8359235: C1 compilation fails with "assert(is_single_stack() && !is_virtual()) failed: type check"

Changes: https://git.openjdk.org/jdk/pull/26462/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359235
  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26462/head:pull/26462

PR: https://git.openjdk.org/jdk/pull/26462