On Fri, 14 Apr 2023 16:36:59 GMT, Jan Lahoda <jlah...@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
