RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory
Jim Laskey
james.laskey at oracle.com
Mon Oct 22 12:07:34 UTC 2018
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
More information about the core-libs-dev
mailing list