Interesting idea...comments below. On Fri, May 10, 2013 at 12:44 PM, Per Bothner <p...@bothner.com> wrote:
> So this idea come to me: Could we just have add a method > that tail-calls a MethodHandle? Maybe some variant of > MethodHandle#invokeAsTailCall(Object... ) > This doesn't require instruction-set or classfile changes, > "only" a new intrinsic method. Of course it's a bit more > complex than that: The actual tailcall to be useful has > to be done in the method that does the invokeAsTailCall, > not the invokeAsTailCall itself. I.e. the implementation > of invokeAsTailCall has to pop only it own (native) stack > frame, but also the caller. > Seems feasible to me. Ideally in any case where Hotspot can inline a method handle call (generally only if it's static final (?) or in constant pool some other way) it should also be able to see that this is a tail invocation of a method call. However...there are cases where Hotspot *can't* inline the handle (dynamically prepared, etc) in which cases you'd want invokeAsTailCall to fail hard, right? Or if it didn't fail...you're not fulfilling the promise of a tail call, and we're back to the debates about whether JVM should support "hard" or "soft" tail calling guarantees. > One problem with invokeAsTailCall is it implies > needless boxing, which may be hard to optimize away. > Perhaps a better approach would be to use invokedynamic > in some special conventional way, like with a magic > CallSite. However, that makes calling from Java more > difficult. > Making it signature-polymorphic, like invokeExact and friends, would avoid the boxing (when inlined). - Charlie
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
