indy-based string-switch proposal

Brian Goetz brian.goetz at oracle.com
Tue Nov 5 21:44:27 UTC 2019


I suspect that having freedom over the ids is a loss overall, which is why we went with the implicit ids in the prototype version.  Of course, if you can demonstrate a clear advantage in actually common cases, that would be interesting.  

Sent from my iPad

> On Nov 5, 2019, at 7:49 PM, Japris Pogrammer <mrjarviscraft at gmail.com> wrote:
> 
> 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
>> 



More information about the amber-dev mailing list