[External] : Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

[Remi Forax]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jorn Vernee" <jvernee at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoyé: Samedi 10 Avril 2021 01:43:49
> Objet: Re: [External] : Re: RFR: 8263087: Add a MethodHandle combinator that
> switches over a set of MethodHandles

> On Apr 9, 2021, at 4:00 PM, John Rose < [ mailto:john.r.rose at oracle.com |
> john.r.rose at oracle.com ] > wrote:

>> The MH combinator for lookupswitch can use a data-driven
>> reverse lookup in a (frozen/stable) int[] array, using binary
>> search. The bytecode emitter can render such a thing as
>> an internal lookupswitch, if that seems desirable. But
>> the stable array with binary search scales to other types
>> besides int, so it’s the right primitive.

> This may be confusing on a couple of points.
> First, the mapping function I’m talking about is not
> a MH combinator, but rather a MH factory, which takes
> a non-MH argument, probably an unsorted array or List
> of items of any type. It then DTRT (internal hash map
> or tree map or flat binary search or flat table lookup or
> lookupswitch or any combination thereof) to get
> an algorithm to classify the array or List elements
> into a compact enumeration [0,N).

> Second, when the input array or List is of int (or
> Integer) then it *might* be a lookupswitch internally,
> and I’m abusing the terminology to call this particular
> case a lookupswitch. But it’s really just a classifier
> factory, whose output is a MH of type K → [0,N) for
> some K. The output might also be ToIntFunction<K>
> for all I care; that can be inter-converted with a MH.

As you said, the classifier is either a lookup switch or a hashmap.get() or a perfect hash function like ordinal(). 
The last two can be already be seen as MH, that you can already compose. 
The only one we can not currently, without generating bytecode, is the lookup switch, so we should have a lookupswitch combinator. 

This does not mean we do not need the tableswitch combinator, it means we need both. 

Firthermore, if we do have both combinators, there is no need to a special mechanism, or am i missing something ? 

Rémi