0

The Javadoc for MethodHandles.foldArguments contains this parenthetical note:

(Note that dropArguments can be used to remove any arguments that either the combiner or the target does not wish to receive. If some of the incoming arguments are destined only for the combiner, consider using asCollector instead, since those arguments will not need to be live on the stack on entry to the target.)

First, I'm confused whether this suggests replacing foldArguments with dropArguments+asCollector, replacing foldArguments+dropArguments with asCollector, replacing foldArguments+dropArguments with foldArguments+asCollector, etc.

Secondly, I don't understand why MethodHandles.asCollector is relevant at all here.

  • The note doesn't say "If you just want to collect arguments into an array, use asCollector", it seems to imply asCollector is a general replacement for foldArguments (possibly in some combination with dropArguments), which it is not.

  • The bit about "live on the stack on entry to the target" seems to imply I should first collect any arguments "destined only for the combiner" into an array with asCollector before sending them to the combiner. I don't understand how adding an array creation and extra level of indirection is going to help anything, especially because if the resulting method handle gets inlined the JVM will try to optimize out the array creation anyway. If the combiner-only args are dropped with dropArguments, the JVM should be able to prove they aren't used in the target. If for some reason the JVM can't prove the combiner-only args are not used in the target and thus must keep them alive, surely the array created by asCollector will be alive and thus keep its contents alive as well. They'll be on the heap rather than the stack, but I don't see how that helps (especially if they're references to objects already on the heap).

  • Java 8 added MethodHandles.collectArguments which combines foldArguments and dropArguments in the obvious way to implement collector-only arguments. The Javadoc collectArguments does not mention asCollector as an alternative, suggesting any advice to use asCollector instead no longer holds, but the foldArguments Javadoc still contains the confusing parenthetical note.

What's the relationship (if any) between MethodHandles.foldArguments and MethodHandle.asCollector?

Jeffrey Bosboom
  • 13,313
  • 16
  • 79
  • 92
  • I know this question is old and low-viewed, but I would still like an answer. – Jeffrey Bosboom Jul 04 '15 at 16:46
  • (anti-Roomba comment 2) – Jeffrey Bosboom Jul 04 '15 at 16:47
  • Java 9 is going to introduce an overload, [`foldArguments(MethodHandle target, int pos, MethodHandle combiner)`](http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.html#foldArguments-java.lang.invoke.MethodHandle-int-java.lang.invoke.MethodHandle-) whose documentation doesn’t have that spurious note. But for the old method without a position parameter, the note is still there and I’d suggest opening an RFE regarding the method’s documentation. – Holger Apr 29 '16 at 17:05

0 Answers0