Understanding javac generated code for record patterns

[srikanth-sankaran]

Hello!

Given this program:

public class X {
  static void print(Rectangle r) {
    if (r instanceof Rectangle(ColoredPoint(Point(int x, int y), Color c),
                               ColoredPoint lr) ) {
        System.out.println("Upper-left corner:");
    }
  }
  public static void main(String[] obj) {
    print(new Rectangle(new ColoredPoint(new Point(0, 0), Color.BLUE),
                               new ColoredPoint(new Point(10, 15), Color.RED)));
  }
}
record Point(int x, int y) {}
enum Color { RED, GREEN, BLUE }
record ColoredPoint(Point p, Color c) {}
record Rectangle(ColoredPoint upperLeft, ColoredPoint lowerRight) {}

javac from JDK21 seems to generate the following code for the method print:

  static void print(Rectangle);
    descriptor: (LRectangle;)V
    flags: (0x0008) ACC_STATIC
    Code:
      stack=4, locals=9, args_size=1
         0: aload_0
         1: instanceof    #7                  // class Rectangle
         4: ifeq          93
         7: aload_0
         8: astore_1
         9: aload_1
        10: invokevirtual #9                  // Method Rectangle.upperLeft:()LColoredPoint;
        13: astore        8
        15: aload         8
        17: instanceof    #13                 // class ColoredPoint
        20: ifeq          93
        23: aload         8
        25: astore_2
        26: aload_1
        27: invokevirtual #15                 // Method Rectangle.lowerRight:()LColoredPoint;
        30: astore        8
        32: aload         8
        34: astore_3
        35: aload_2
        36: invokevirtual #18                 // Method ColoredPoint.p:()LPoint;
        39: astore        8
        41: aload         8
        43: instanceof    #22                 // class Point
        46: ifeq          93
        49: aload         8
        51: astore        4
        53: aload_2
        54: invokevirtual #24                 // Method ColoredPoint.c:()LColor;
        57: astore        8
        59: aload         8
        61: astore        5
        63: aload         4
        65: invokevirtual #28                 // Method Point.x:()I
        68: istore        8
        70: iload         8
        72: istore        6
        74: aload         4
        76: invokevirtual #32                 // Method Point.y:()I
        79: istore        8
        81: iload         8
        83: istore        7
        85: getstatic     #35                 // Field java/lang/System.out:Ljava/io/PrintStream;
        88: ldc           #41                 // String Upper-left corner:
        90: invokevirtual #43                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        93: goto          110
        96: astore_1
        97: new           #51                 // class java/lang/MatchException
       100: dup
       101: aload_1
       102: invokevirtual #53                 // Method java/lang/Throwable.toString:()Ljava/lang/String;
       105: aload_1
       106: invokespecial #57                 // Method java/lang/MatchException."<init>":(Ljava/lang/String;Ljava/lang/Throwable;)V
       109: athrow
       110: return

This looks sub-optimal as well a bit irregular to me.

1. After the invocation of the pattern accessor such as 10: invokevirtual #9 // Method Rectangle.upperLeft:()LColoredPoint;, why would we at bci 17 do 17: instanceof #13 // class ColoredPoint - isn't this redundant ?? If the record class underwent any incompatible changes, the accessor invocation would have thrown an exception and if it finished normally the stack will have a ColoredPoint - why would I have to check it again with instanceof ?
2. See that the next accessor invocation 27: invokevirtual #15 // Method Rectangle.lowerRight:()LColoredPoint; does not have an instanceof check - what would explain this ?

[srikanth-sankaran]

@stephan-herrmann , @jarthana @mpalat @iloveeclipse - what am I overlooking ??

[srikanth-sankaran]

Never mind. I found out what is going on: org.eclipse.jdt.core.tests.compiler.regression.RecordPatternTest.test15() illuminated me :)