新型 Java 17 型模式匹配开关如何在引擎盖下工作？

Question

How does the new Java 17 type pattern matching switch works under the hood? As the feature is fairly new, this question doesn't talk about it.

Reminder: for this code to work under Java 17, you need to enable preview features

public static void test (Object o) {
  System.out.println(switch(o){
    case Number n -> "number " + n;
    case Enum e -> "enum " + e;
    case String s -> "string " + s;
    default -> "other " + o;
  });
}

Disassembled version of the code above using javap -c :

   0: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
   3: aload_0
   4: dup
   5: invokestatic  #13                 // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object;
   8: pop
   9: astore_1
  10: iconst_0
  11: istore_2
  12: aload_1
  13: iload_2
  14: invokedynamic #19,  0             // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I
  19: tableswitch   { // 0 to 2
                 0: 44
                 1: 58
                 2: 74
           default: 90
      }
  44: aload_1
  45: checkcast     #23                 // class java/lang/Number
  48: astore_3
  49: aload_3
  50: invokedynamic #25,  0             // InvokeDynamic #1:makeConcatWithConstants:(Ljava/lang/Number;)Ljava/lang/String;
  55: goto          96
  58: aload_1
  59: checkcast     #29                 // class java/lang/Enum
  62: astore        4
  64: aload         4
  66: invokedynamic #31,  0             // InvokeDynamic #2:makeConcatWithConstants:(Ljava/lang/Enum;)Ljava/lang/String;
  71: goto          96
  74: aload_1
  75: checkcast     #34                 // class java/lang/String
  78: astore        5
  80: aload         5
  82: invokedynamic #36,  0             // InvokeDynamic #3:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
  87: goto          96
  90: aload_0
  91: invokedynamic #39,  0             // InvokeDynamic #4:makeConcatWithConstants:(Ljava/lang/Object;)Ljava/lang/String;
  96: invokevirtual #42                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
  99: return

Given this key line:

  14: invokedynamic #19,  0             // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I

It looks like Java converts the object into an int in an auto-generated int typeSwitch (Object, int) method, of which I can't see the generated code. The goal of this conversion is then to be able to use a regular switch table over int values.

At first, I thought that hashCode of was used, ie object.getClass().hashCode() , as it is done with switch over String, but in fact Class object's hash code isn't constant over consecutive runs of the JVM. So it's impossible unless the mapping table is rebuilt at every execution, what I doub about.

So, the questions are:

What does this typeSwitch method do?

Is it smarter than a chain of if instanceof else if instanceof? Is that possible?

What's the purpose of the additional int passed?

Answer 1

The invokeDynamic instruction (upon first being hit) calls the SwitchBootstraps.typeSwitch() method.

The last argument of the SwitchBootstraps.typeSwitch() method (the labels parameter) is in this case the list of classes in the switch: Number.class , Enum.class , String.class

The SwitchBootstraps.typeSwitch() bootstrap method checks the labels parameter for correctness and then returns a ConstantCallSite for the SwitchBootstraps.doTypeSwitch() method that does the effective handling (ie the final execution of the invokeDynamic instruction).

If you look at what SwitchBootstraps.doTypeSwitch() does: it iterates over the list of classes and returns the first found match (with some provision of restarting the iteration, I don't know why this is needed).

Answer 2

What does this typeSwitch method do?

It takes an Object , figures out its real type, then maps that to an integer which represents the label index. The integer is then used for the following conventional tableswitch instruction that you see.

This is implemented in an internal class called java.lang.runtime.SwitchBootstraps by calling the typeSwitch method. The method is passed an additional Object[] which will contain the Class object denoting the type of each of the case labels of the type switch.

Is it smarter than a chain of if instanceof else if instanceof?

The SwitchBootstraps class uses a for loop that tests the alternatives using Class.isAssignableFrom .

The comment above that code says:

// Dumbest possible strategy

Is that possible?

I don't know. Possibly.

It is also possible that the JIT compiler will do something clever when compiling a call to typeSwitch . If the SwitchBootstraps code is only called when interpreting bytecodes, the "dumb" approach is... just fine.

It is also possible that they intend to put some smarts into the JIT compiler in a future release.

What's the purpose of the additional int passed?

I'm not sure. It determines where the typeswitch method starts searching in the Objects[] that represents the labels.

Looking at the code, the for loop I mentioned above also copes with numbers, characters and strings in the labels array. So I suspect that this same code is used (or intended to be used) for classic and string switch statements. If that is the case, I suspect that the additional int is to provide an alternative way to implement switch case drop-through.

---

If you want more detailed information, I recommend that you do what I did. Trawl through the OpenJDK source code for Java 17.

To use your metaphor: look under the hood yourself!