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

[Jan Lahoda]

On Fri, 14 Apr 2023 16:45:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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 ever 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).

FWIW, I've changed the bootstraps to not initialize the enum classes. But, I don't think I can promise `ConstantCallSite` will be used.

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

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