idea: MethodHandle#invokeTailCall

[Remi Forax]

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
>     mlvm-dev at openjdk.java.net
>     http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev