indy-based string-switch proposal

[Japris Pogrammer]

Of course, JIT part is expected to be aware of this cases.
The question is still if we want the compiler be able to specify the branch
IDs himself. I personally am for this approach as it allows more compact
switch-tables be used as it preserves an explicit way to specify multiple
labels corresponding to the single branch. Eg., having 100 branches with
50% duplicates using explicit IDs would generate twice as compact
switch-table as if it was done on one-ID per label basis. In the end, the
way described in the original patch does not require any additional slots
for it (both in const pool and in bootstrap-arguments) due to usage of
pages.

вт, 5 нояб. 2019 г. в 21:40, Remi Forax <forax at univ-mlv.fr>:

> ----- Mail original -----
> > De: "John Rose" <john.r.rose at oracle.com>
> > À: "Brian Goetz" <brian.goetz at oracle.com>
> > Cc: "amber-dev" <amber-dev at openjdk.java.net>
> > Envoyé: Mardi 5 Novembre 2019 19:32:58
> > Objet: Re: indy-based string-switch proposal
>
> > On Nov 5, 2019, at 1:06 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> >>
> >> Note that we want to use this technique for all switches except those
> over int
> >> and smaller.
> >
> > There are cases where smaller types should be handed to the library also.
> > I know this would be profitable for character classification switches
> (usable
> > by parsers!), which is why I called out that case at the end of my long
> message.
> > LLVM is having some fun with those; we should too.
>
> I wonder if it's not better for this specific case to has a specific
> optimization of the tableswitch inside the JIT so some existing tableswitch
> will be optimized has well without recompiling.
>
> Rémi
>