indy-based string-switch proposal

[Japris Pogrammer]

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.
>
>