idea: MethodHandle#invokeTailCall

[Alexander Turner]

Hi Per, the snag with expecting code to be inlined is that so much of
modern JVM work uses instrumentation. If the JVM will inline the non
instrumented code it probably will not / cannot do so for instrumented
code. Thus code coverage and performance steps in CI will become non valid.

To put this another way - one should never rely on inlining for semantic
behaviour.

- AJ

On Saturday, 11 May 2013, Per Bothner wrote:

> 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/
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130511/62c89361/attachment.html