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

Inefficient compilation of Pattern Matching for instanceof

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 14
    • Fix Version/s: 15
    • Component/s: tools
    • Subcomponent:
    • Resolved In Build:
      b08

      Description

      JDK 14 EA b32 compiles

      class Example {
          static void example(Object e) {
              if (e instanceof String s) {
                  nop(s);
              }
          }

          public static void main(String[] args) {
              example(new Object());
              example("");
          }

          static void nop(String s) {
          }
      }

      into

        static void example(java.lang.Object);
          descriptor: (Ljava/lang/Object;)V
          flags: (0x0008) ACC_STATIC
          Code:
            stack=2, locals=3, args_size=1
               0: aload_0
               1: astore_2
               2: aload_2
               3: instanceof #7 // class java/lang/String
               6: ifeq 26
               9: aload_2
              10: checkcast #7 // class java/lang/String
              13: dup
              14: astore_1
              15: aload_2
              16: checkcast #7 // class java/lang/String
              19: if_acmpne 26
              22: aload_1
              23: invokestatic #9 // Method nop:(Ljava/lang/String;)V
              26: return

      which contains two comparisons (at offsets 6 and 19).
      Presence of the second one is redundant,
      and quite unfortunate for bytecode analysis tools,
      such as code coverage tool JaCoCo,
      because one of the two branches of this comparison is never executed
      and will be present in code coverage report as uncovered,
      whereas looking at the source code users will expect to see only one comparison.
      See attached screenshots.

      Also see https://mail.openjdk.java.net/pipermail/amber-dev/2020-January/005477.html
      according to Remi Forax
      > clearly the generated bytecode should be cleaned up

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jlahoda Jan Lahoda
                Reporter:
                godin Evgeny Mandrikov
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: