RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2]

Jan Lahoda jlahoda at openjdk.org
Thu Apr 20 13:51:52 UTC 2023

On Wed, 19 Apr 2023 16:45:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision:
>>  - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type.
>>  - Reflecting review comments.
>>  - Fixing exhaustiveness for unsealed supertype pattern.
>>  - No need to enable features after error reported.
>>  - SwitchBootstraps.typeSwitch should not initialize enum classes.
>>  - A prototype of avoiding enum initialization.
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:
>> 277:     }
>> 278: 
>> 279:     private static int lazyDoEnumSwitch(Enum<?> target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass, MutableCallSite callSite) throws Throwable {
> can `doEnumSwitch` be folded into `lazyDoEnumSwitch`? just a suggestion, I'm OK with either way just that now it is not clear that we need two methods here. Also in `doEnumSwitch` and out of curiosity what example of user code could hit this section:
>             if (label instanceof Class<?> c) {
>                 if (c.isAssignableFrom(targetClass))
>                     return i;
>             }
> EDIT: nvm I found one example

The intent here is to avoid eager initialization of enums - so, until the enum is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't compute any results, except the result for `null`), which is then replaced with `doEnumSwitch` using the enum constants directly.

The enum switches support patterns as well, so something like:

enum E {A;}
E e = ...;
switch (e) {
     case E ee -> {}

is valid, and should trigger the part with Class labels.


PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172623143

More information about the compiler-dev mailing list