On Fri, 14 Apr 2023 16:45:36 GMT, Roger Riggs <[email protected]> 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
