RFR: 8300543 Compiler Implementation for Pattern Matching for switch

[Jan Lahoda]

On Fri, 14 Apr 2023 16:10:49 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> FWIW, a sketch on how avoiding the enum initialization might look like is here:
>> https://github.com/lahodaj/jdk/compare/JDK-8300543...lahodaj:jdk:JDK-8300543-lazy-enum?expand=1
>> 
>> more work needed to make that work for `typeSwitch`, and to combine that with #9779.
>
> 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.

-------------

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