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