First of all, if a JVM were to attempt this optimization for tail calls using the ordinary method call bytecodes, it would break existing programs that are written to rely on stack frame inspection.
So the only solution is to add a new bytecode for tail calling methods, so that this bytecode can be used from non-Java languages without impacting existing code; however there's no such bytecode yet.
Self-tail calls (where a function calls itself in tail position) can be compiled as a goto, however this is not as general as full tail call elimination (you cannot implement a state machine consisting of several functions this way, for insance).
Also, an arbitrary set of tail-recursive functions can be compiled into something that fakes a call stack using a heap-allocated data structure, with a top-level trampoline that drives an interpreter loop. However this incurs a significant performance penalty, and requires a whole-program transform. When you hear about Scheme implementations on the JVM that implement tail calls and call/cc, they generally use this trick, and as a result as too slow to be useful.
So, right now there's no good solution for tail calls on the JVM, and it would require changes to the JVM to implement in full generality.
> First of all, if a JVM were to attempt this optimization for tail calls using the ordinary method call bytecodes, it would break existing programs that are written to rely on stack frame inspection.
That is not a bug, that's a feature. Too bad the feature request for hanging people who write programs that rely on stack frame inspection didn't go trough.
> Self-tail calls (where a function calls itself in tail position) can be compiled as a goto
Right, that's the example that I had in mind.
I can see that for more complicated situations something more would be required, but I always figured that if the JVM is turing complete that it should be possible to 'target' any language to it without having to invent special bytecodes. Probably this is a direct consequence of the JVM and java being developed in tandem, it is not as general as I thought it was.
This is why clojure has a special form for tail call where you can "recur" a loop by re-binding the variables. When proper tail call comes to JVM, it'll be possible to do write the loop as a function call instead of hiding it inside a function.
In java, you could use the "while" keyword for that.
Anyway, tail-calls aren't necessarily loops. If I'm not mistaken, tail-call optimisation for looping constructs only (which the poster a few levels above probably had in mind) wouldn't require a special byte code.
With the added benefit that it will warn you if you're not really in tail position. The only place where recur falls flat is with mutual recursion in which case you need to use trampoline. I love me some Clojure.
First of all, if a JVM were to attempt this optimization for tail calls using the ordinary method call bytecodes, it would break existing programs that are written to rely on stack frame inspection.
So the only solution is to add a new bytecode for tail calling methods, so that this bytecode can be used from non-Java languages without impacting existing code; however there's no such bytecode yet.
Self-tail calls (where a function calls itself in tail position) can be compiled as a goto, however this is not as general as full tail call elimination (you cannot implement a state machine consisting of several functions this way, for insance).
Also, an arbitrary set of tail-recursive functions can be compiled into something that fakes a call stack using a heap-allocated data structure, with a top-level trampoline that drives an interpreter loop. However this incurs a significant performance penalty, and requires a whole-program transform. When you hear about Scheme implementations on the JVM that implement tail calls and call/cc, they generally use this trick, and as a result as too slow to be useful.
So, right now there's no good solution for tail calls on the JVM, and it would require changes to the JVM to implement in full generality.