# Failure analysis

The library intrinsic _copyOfRange does not guard for start indices that are larger than the length of the source arrays. At the same time, _copyOfRange indicates that the arguments do have the necessary guards (i.e., are validated). As a result, the escape analysis can remove a number of nodes, which in turn leads to the removal of the ArrayCopyNode generated by _copyOfRange. Consequently, we never generate the required guard for the start index.

For reference: if we turn off the escape analysis with -XX:-DoEscapeAnalysis, we generate the appropriate guard during ArrayCopy macro expansion and the issue does not surface.

# Original description

A DESCRIPTION OF THE PROBLEM :
### Description:

```
public class FailedToCatch {

    public static void main(String[] var0) {
        Object[] arr = new Object[10];
        int catchTime = 0;
        for(int i = 0; i < 20000; i++) {
            try {
                m(arr, 15, 20);
            } catch (ArrayIndexOutOfBoundsException var4) {
                catchTime++;
                for(int loopIndex = 1; loopIndex < 100; loopIndex++) {
                }
            }
        }
        System.out.println("Catch Time: " + catchTime);
    }
    static Object[] m(Object[] var0, int var1, int var2) {
        return Arrays.copyOfRange(var0, var1, var2, Object[].class);
    }
}
```

The test program shown above is designed to catch the `ArrayIndexOutOfBoundsException` when invoking the method `m()`. According to the code logic, the expected catch time should be 20,000. However, when executing this test program on OpenJDK 11, 17, and 21, the actual catch time is incorrect. For example, running the program on OpenJDK 11 outputs `Catch Time: 2560`.

**Expected Behavior:**

The catch time should be 20,000, indicating that the exception is successfully caught every time the method `m()` is invoked.

**Observed Behavior:**

The catch time is incorrect when executing the test program on OpenJDK 11, 17, and 21, suggesting that the `ArrayIndexOutOfBoundsException` is not consistently caught. This issue does not occur when running the program on OpenJDK 8.

Test Program : https://drive.google.com/file/d/1S4ogjVOUBFjmfyyv666MZXNaFsgtfOl_/view?usp=sharing

macOS version:

```java
Software:

    System Software Overview:

      System Version: macOS 13.2 (22D49)
      Kernel Version: Darwin 22.3.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: MacBook Pro
      User Name: MacBook
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 1 day, 2 hours, 19 minutes

Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro18,1
      Model Number: MK193CH/A
      Chip: Apple M1 Pro
      Total Number of Cores: 10 (8 performance and 2 efficiency)
      Memory: 16 GB
      System Firmware Version: 8419.80.7
      OS Loader Version: 8419.80.7
      Activation Lock Status: Disabled
```

OpenJDK version:

```
openjdk version "11.0.21" 2023-10-17
OpenJDK Runtime Environment Temurin-11.0.21+9 (build 11.0.21+9)
OpenJDK 64-Bit Server VM Temurin-11.0.21+9 (build 11.0.21+9, mixed mode)

openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)

openjdk version "21.0.1" 2023-10-17 LTS
OpenJDK Runtime Environment Temurin-21.0.1+12 (build 21.0.1+12-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.1+12 (build 21.0.1+12-LTS, mixed mode)
```

REGRESSION : Last worked in version 8u391


FREQUENCY : always