RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory

[Hannes Wallnöfer]

This would definitely be a useful addition to the public MethodHandles API. Achieving this functionality with currently available means is extremely tricky and certainly does not produce readable or maintainable code.

Hannes

> Am 22.10.2018 um 14:07 schrieb Jim Laskey <james.laskey at oracle.com>:
> 
> Thank you for doing this. The MethodHandle changes will simplify many a use case.
> 
> Cheers,
> 
> — Jim
> 
> 
>> On Oct 22, 2018, at 6:58 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>> 
>> Hi,
>> 
>> StringConcatFactory uses a customized internal foldArguments
>> implementation which takes positional arguments to avoid intermediary
>> permutation steps, see JDK-8165492[1]. My intent has been to clean this
>> up for possible inclusion in the public API.
>> 
>> In preparation of that, I realized that we could probably profit from a
>> filtering combinator on top of the existing folding one. Said and done:
>> 
>> http://cr.openjdk.java.net/~redestad/8212726/jdk.00/
>> https://bugs.openjdk.java.net/browse/JDK-8212726
>> 
>> Using this new MethodHandles.filterArgumentsWithCombiner in place of
>> MHs.dropArguments + MHs.foldArgumentsWithCombiner gets rid of a
>> significant number of MethodHandles with retained performance
>> characteristics. In startup tests exercising indified String
>> concatenation the number of generated classes drops by ~25-30%, with a
>> measurable improvement in startup time as a result. Subjectively it also
>> makes the code in StringConcatFactory easier to read and follow.
>> 
>> While this surely strengthens the case to include these in the public
>> API, I'd like to move ahead with this as an internal optimization first
>> and propose MethodHandles.filter-/foldArgumentsWithCombiner as public
>> API points as a follow-up: apart from improving the javadoc we need to
>> work out specification for corner cases - especially illegal values -
>> and harden the implementation with more tests. I'm sure there might be
>> opinions about the naming of these methods, too... :-)
>> 
>> Thanks!
>> 
>> /Claes
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8165492
>