On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda <jlah...@openjdk.org> wrote:
> Consider code like:
>
> void test(Object o) {
> switch (o) {
> case X1 -> {}
> case X2 -> {}
> ...(about 100 cases)
> ```
>
> javac will compile the switch into a switch whose selector is an indy
> invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the
> types in the cases.
>
> `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s
> performing `instanceof` checks between the switch's selector and the given
> case type. The problem is that when the number of cases is high enough, (more
> than ~40-50), the chain gets too long, and the tests won't inline anymore.
> This then leads to a very bad performance, when compared to manually written
> if-instanceof-else-if-instanceof- chain.
>
> The proposal herein is to use bytecode (written using the ClassFile
> API/library) instead of the `MethodHandle`s chain. The overall performance of
> this seems to be similar to the manually written
> if-instanceof-else-if-instanceof- chain.
>
> Using the benchmark from the bug, and this patch, I am getting:
>
> MyBenchmark.testIfElse100 thrpt 5 521826.326 ± 7510.042 ops/s
> MyBenchmark.testSwitch100 thrpt 5 505440.170 ± 3757.178 ops/s
>
>
> The most tricky part of this new way to generate the tests is handling of
> non-type case labels, and in particular cases with enum constant labels. The
> resolution of enum constants is deferred as much as possible, by using an
> indirection through the `ResolvedEnumLabels`.
>
> Further improvements may be possible, esp. for some specific cases (like all
> cases having a type, and the type being a final class).
src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 425:
> 423: if (element.label() instanceof Class<?>
> classLabel) {
> 424: cb.aload(0);
> 425:
> cb.instanceof_(classLabel.describeConstable().get());
You should use orElseThrow() (see the javadoc) instead of get(). This code does
not work because hidden class Class are not denotable. My first idea was that
it was not a real problem because no code generated by javac will use an hidden
class but this is not true. A type pattern can use the current class and this
class can be loaded by a defineHiddenClass.
A way to solve that issue is to store the non denotable classes inside a list
and send that list as a class data when calling defineHiddenClass.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381775426
