Many of us would like full tail-call support in the JVM,
but it of course not as trivial a change as one would like.
The "clean" solution is to add a new bytecode (or perhaps
multiple bytecodes for virtual, static, etc), which is a
Big Deal, plus is difficult to invoke from Java. Adding
switches or annotation is easier but it is difficult to
do so at smaller granularity than an entire method.
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.
An invokeAsTailCall would only be valid immediately
before (in the control flow) of a return, and not in
any exception handler block.
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.
Anything , just some thoughts. I'm certainly not qualified
to do the needed HotSpot hacking.
--
--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
