On Fri, 3 Jun 2022 15:18:52 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> 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).
>
> The same could be done for the public `dropArgumentsToMatch` I think.
I'm not so sure.
First of all we're no worse than before with the defensive copying here. Second
of an optimizing compiler might theoretically be able to see that the array we
get from the toArray is always fresh and not escaping anywhere in any
well-behaved collection, so the clone could be elided. But if not then both
toArray and clone are intrinsified operations that are heavily optimized and
pretty fast even when interpreting, so emulating it with an external loop might
end up taking more time even at peak. While likely taking longer to reach that
peak. Using dumb, shared and common code (especially things that get JITted
early anyhow) is nice in areas that see most action during startup/warmup.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8923
