RFR: 8300543 Compiler Implementation for Pattern Matching for switch

Roger Riggs rriggs at openjdk.org
Fri Apr 14 16:48:32 UTC 2023

On Fri, 14 Apr 2023 16:36:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> FWIW... an observation from working on [JDK-7176515](https://bugs.openjdk.org/browse/JDK-7176515). This is probably redundant but here goes anyway.
>> In the compiler there are currently three different ways of handling enums in switch statements:
>> 1. The old way, where a separate lookup class is generated for traditional switch-on-enum statements
>> 2. The `ordinal()` way, which is an optimization available when the `enum` type is defined in the same file as the `switch` statement (what JDK-7176515 adds)
>> 3. The new way using bootstrap methods, which is used by the pattern matching stuff
>> My observation is simply that the old way <span>#</span>1 should be completely eliminated and folded into <span>#</span>3. <span>#</span>1 is just a hold-over from before INVOKEDYNAMIC. Using a bootstrap method is "the right way" to handle enums. Instead, traditional switch-on-enum should be handled as a degenerate case of pattern switch with enums. This will simplify the code and eliminate the ugly extra lookup class.
> Well, I'm aware of this, and https://github.com/openjdk/jdk/pull/9779 even optimizes the case where the `enumSwitch` only gets enum constants as parameters.
> And, overall, it is fairly easy to implement, I think I've had at least one implementation in the past. But, the last time I was experimenting with this, there IIRC was a performance hit for using the indy/condy (IIRC it worked as a condy/ldc for a mapping array - but it could as easily be an indy doing the mapping as such). So, frankly, to me, simplifying the compiler slightly (in maybe ~10 years, because we would still need to keep the current desugaring for targets that don't have the bootstrap) while slowing down all other code is not a good balance. *If* we can make the indy/condy at least as fast as the current code, (or faster,) then sure, this is the right way to go. And, as far as javac is concerned that is not really difficult.

Is it every too early in JDK startup (Phase 1) to use #3? But you'll find out pretty quick if the JDK won't start.  But it might constrain where we can use Pattern matching (and it won't be the first feature that can't be used in Phase 1).


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

More information about the compiler-dev mailing list