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 <p...@bothner.com
> <mailto: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.
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
p...@bothner.com http://per.bothner.com/
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
