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

Vicente Romero vromero at openjdk.org
Thu Apr 20 18:27:56 UTC 2023


On Thu, 20 Apr 2023 16:54:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

I see, thanks for the explanation, this is nice

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

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


More information about the core-libs-dev mailing list