RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory
Hannes Wallnöfer
hannes.wallnoefer at oracle.com
Wed Oct 24 16:42:33 UTC 2018
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
>
More information about the core-libs-dev
mailing list