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