Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8323682

C2: guard check is not generated in Arrays.copyOfRange intrinsic when allocation is eliminated by EA



    • b99
    • 9
    • b17


      # 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

      ### 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) {
                      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:


          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 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


        Issue Links



              dlunden Daniel Lunden
              webbuggrp Webbug Group
              0 Vote for this issue
              9 Start watching this issue