RFR: 8287442: Reduce list to array conversions in java.lang.invoke.MethodHandles [v2]
Jorn Vernee
jvernee at openjdk.java.net
Fri Jun 3 15:53:44 UTC 2022
On Fri, 27 May 2022 19:52:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>
> Review comments, eagerly convert sooner in tryFinally
src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5266:
> 5264: */
> 5265: public static MethodHandle dropArguments(MethodHandle target, int pos, List<Class<?>> valueTypes) {
> 5266: return dropArguments(target, pos, valueTypes.toArray(new Class<?>[0]), false);
A bit unfortunate that we can't trust this `toArray` to do a copy. I was going to suggest Stream, but it has the same issue (someone might have a custom stream implementation).
I do think a manual copy of the array is possible by having a loop though:
Suggestion:
Class<?>[] ptypes = new Class<?>[valueTypes.size()];
for (int i = 0; i < ptypes.length; i++) {
ptypes[i] = valueTypes.get(i);
}
return dropArguments(target, pos, ptypes, false);
(or, maybe extract such a loop to a helper method for clarity).
src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5269:
> 5267: }
> 5268:
> 5269: static MethodHandle dropArguments(MethodHandle target, int pos, Class<?>[] valueTypes, boolean trusted) {
Having a boolean that flips the behaviour makes it harder to know what that `true` or `false` literal at the call site does. I'd suggest splitting this into `dropArgumentsTrusted`, which doesn't clone the array, and `dropArguments` which always makes a copy (and the latter calls former). WDYT?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8923
More information about the core-libs-dev
mailing list