On May 7, 2013, at 3:44 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > I understand why you need a trampoline for a virtual call but > why do you need a trampoline for a static call ?
The arguments have to be reordered, since the MH is a leading argument that must be deleted (in the case of a DMH). For compiled calls, this means register shuffling. (In JDK 7 it's worse for compiled calls. Argument reordering is done in several trampolines: First convert the compiled call to interpreter argument format, then tweak the interpreter stack, then convert back to compiled argument format.) The cost of reordering arguments could be hidden by inlining the target of the DMH into the DMH trampoline (and/or making an alternative entry point to the target method). We don't do this yet. To put it another way, there's a choice in the system for sharing vs. customizing such trampolines. We share more than customize, currently. Cases like yours cause us to note the downsides of this choice. If you share argument reordering code, then you have two indirect jumps. First, to the DMH compiled code handler. Second, after the handler shuffles arguments, to the target of the DMH (which is not constant from the POV of the compiled code handler). — John P.S. The private linkToVirtual, linkTo* intrinsics were introduced in the JDK 8 implementation to decouple the argument shuffling from the actual jump to the target method, so that the former could be managed separately. The shuffling code is generated by makePreparedLambdaForm.
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
