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

Reply via email to