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

[Jim Laskey]

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