idea: MethodHandle#invokeTailCall

[Per Bothner]

On 05/10/2013 01:32 PM, Charles Oliver Nutter wrote:
> Interesting idea...comments below.
>
> On Fri, May 10, 2013 at 12:44 PM, Per Bothner <per at bothner.com
> <mailto: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.

Fail hard is probably the wrong thing to do - except when debugging.
I think what you want is the default to not fail if it can't pop
the stack frame, but that there be a VM option to throw an Error
or even do a VM abort in those case.  You'd run the test suite
in this mode.

That assumes that there is well-specified a minimal set of
circumstances in which the inlining is done correctly,
so a compiler or programmer can count on that, and that this
set is sufficient for low-overhead tail-call elimination.

I'll be happy when I can run Kawa with --full-tailcalls
as the default with at most a minor performance degradation.
If we don't get there, I'll be satisfied if at least it is
faster (and simpler!) than the current trampoline-based
implementation.

>     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).

Even better.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/