Doug Lea wrote:
Could you remind us why Java doesn’t allow tail-recursion optimization?
Heh – all things allow “as if” optimizations, ‘cause how you gonna know? 😉
Java likes to hand out decent stack traces, but these are specifically not language designed or required – but in practice decent stack traces ARE required as a primary debugging tool.
You might be able to do tail-RECURSION optimization “as if” with counters somehow.
You might have more trouble doing tail-CALL optimization with counters – and that might mess with the usual Java security model – all things below a security call can get priviledges – which in practice means a stack-crawl the state of the stack around the security call being “known” to the VM (and to the compiler for optimizations).
So: do-able I believe, with some work to keep the security stuff functional & fast. Stack-traces for recursion are probably OK truncated (since primary usage is debugging, and no language spec requirement). Stack-traces for tail-calls get chopped is more problematic. I’m open to suggestions here (maintain a fake 2nd lower-cost stack ? append frame “tokens” into a buffer ? )
Any Java language experts Out There want to chime in here?