indy-based string-switch proposal

[Brian Goetz]

The actual code organization (one vs multiple files, package 
organization) should surely be revisited once we have a better sense of 
the shape of the final answer, but it is probably premature to worry too 
much about it now.  The primary focus at this point should be 
testability (for quality and performance), so we can compare different 
implementations (linear search, binary search, generated perfect hash) 
on a level playing field.  The tests that are there are quite 
rudimentary; I'd like to have some generative testing and compare 
results across multiple implementations.

Factoring out the call site factories is fine and will help with 
testability; the current organization was just the path of least 
resistance when writing it.

On 11/17/2019 6:53 AM, Japris Pogrammer wrote:
> I'd like to suggest the following two minor changes to SwitchBootstraps
> class which would help in organizing it:
>
>     1. Move it to sub-package in which all switch-specific components would
>     be present. This would allow having multiple related classes in one place,
>     yet being separated from other runtime components (considering that more of
>     them may come in the future). The only drawback I can see is minor increase
>     in length of related class-pool entries (not the count of them) in classes
>     using SwitchBootstraps due to a bit longer internal name, but it doesn't
>     seem to be a problem.
>     2. Move exact implementations of CallSite-creation logic out of the very
>     SwitchBootstraps class enabling their polymorphism. The ides is to have
>     current implementations present as separate classes (for example,
>     implementing some kind of SwitchCallSiteFactory<T> whose only purpose is
>     creating the very CallSites), to whom SwitchBootstraps delegates (having
>     them stored in its static final fields set at class-load). Used
>     implementation can be overridden via system property (as done by
>     StringConcatFactory). While this may seem as complicating the whole
>     idea, it has multiple advantages behind it. First of all, it enables much
>     easier testing and benchmarking of these implementations as there is no
>     need to place these implementations in separate places as they are no
>     longer hardcoded. Second, it enables users out of OpenJDK to use their own
>     implementations in domain-specific cases (or, they may find even better
>     implementations and have them proposed to OpenJDK). At last, it makes it
>     easier to create modularized slim-fat-JARs as all unused implementation
>     classes may be cut-off (*why have long-switch specific-logic if there are
>     no long switches in my micro-service*). As of performance impact, there
>     don't seem to be any problems with it as, while the fields are static
>     final, monomorphic inline caching may be performed. In the end, these
>     methods are called once for each switch expression creation so having one
>     extra stack-frame on the path is fine.
>
>
> ср, 6 нояб. 2019 г. в 00:48, John Rose <john.r.rose at oracle.com>:
>
>> On Nov 5, 2019, at 1:44 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>>
>> 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.
>>
>>
>> That sounds right to me too.  You need a lot of machinery to make them
>> explicit,
>> and it can only help when there are lots of duplicates.  Probably, if we
>> *need* to
>> deal with duplicates, there’s a “softer” way to do it, such as using
>> implicit IDs and
>> grouping the duplicate-branching cases with some other signal, such as an
>> “I’m
>> with him” optional flag.
>>
>>