On Thu, 20 Apr 2023 16:31:33 GMT, Vicente Romero <vrom...@openjdk.org> wrote:
>> yep I found a similar test case triggering this code > > could you explain a bit more the relation between `lazyDoEnumSwitch` and > `doEnumSwitch` because my understanding is that `lazyDoEnumSwitch` is > invoking `doEnumSwitch` so to me whenever `lazyDoEnumSwitch` is invoked there > will be an immediate invocation of `doEnumSwitch` that's why I thought they > could be folded together So, when the `enumSwitch` bootstrap is called, the enum class may or may not be initialized. So, to avoid initialization, we only do lightweight checks, and construct a `MutableCallSite` with `lazyDoEnumSwitch` as a target. When the `CallSite` is invoked with an actual selector value, two options may arise: a) the selector value is null. The `lazyDoEnumSwitch` itself returns -1. b) the selector value is not null. The enum class must already be initialized (I believe). So, we create (hopefully) better structure to do the categorization, based on `doEnumSwitch`, and set that into the `CallSite`. Further calls will use this new `doEnumSwitch` based categorization directly, without calling `lazyDoEnumSwitch`. The current call will manually delegate to the `doEnumSwitch` version, but that should only happen "once" (or a small number of times, due to running in different threads, etc.). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172863795
