idea: MethodHandle#invokeTailCall

[Alexander Turner]

Remi,

You are so correct! However - I was talking about CI no jee :)

On Saturday, 11 May 2013, Remi Forax wrote:

> On 05/11/2013 12:24 PM, Alexander Turner wrote:
> > 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.
>
> The VM inlines instrumented codes if it inlines the same code written by
> hand,
> the fact that the code is added at load time or runtime doesn't change
> the way the inlining is done.
> Now, a lot of instrumentation agents tend to make the bytecode too big,
> that's why the VM often doesn't inline the instrumented code.
>
> This problem is really something that we as a community should tackle,
> if we want JEE to still exist in 10 years.
> If you take a look to all current implementations, it's full of
> generated proxies,
> AOP like transformations etc. that basically box everything to an
> Object, store things in thread locals, etc.
>
> I see all JEE implementations has poorly written dynamic language runtimes,
> (gosh no of them use invokedynamic :)
> I think we should take a look to the other Java and see what can be
> improved.
> And while at there, we should make JEE API composable (try to use JBoss
> Foo with Spring Bar) and
> get ride of the container idea (no container => no proxy, no dual
> representations, etc),
>
> JEE really needs some love.
>
> >
> > To put this another way - oneshould never rely on inlining for
> > semantic behaviour.
> >
> > - AJ
>
> Rémi
>
> >
> > 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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130511/3007c7f9/attachment-0001.html