RFR: 8300543 Compiler Implementation for Pattern Matching for switch

[Archie L. Cobbs]

On Thu, 13 Apr 2023 12:07:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Note that currently, a `switch` over an enum will already trigger initialisation of the enum class because of the need to compute the relevant mapping array by the synthetic helper class, see [JDK‑7176515] for details.
>> - https://github.com/openjdk/jdk/pull/10797
>> 
>> [JDK‑7176515]: https://bugs.openjdk.org/browse/JDK-7176515 "[JDK‑7176515] ExceptionInInitializerError for an enum with multiple switch statements"
>
> 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.

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

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