JDK-8237528 : Inefficient compilation of Pattern Matching for instanceof
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-20
  • Updated: 2020-07-01
  • Resolved: 2020-01-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15 b08Fixed
Related Reports
Duplicate :  
Relates :  
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

Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/2a46b7b81e78 User: jlahoda Date: 2020-01-29 09:39:02 +0000
29-01-2020