idea: MethodHandle#invokeTailCall

[Charles Oliver Nutter]

Interesting idea...comments below.

On Fri, May 10, 2013 at 12:44 PM, Per Bothner <per at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130510/ffd9cbd7/attachment.html