Doug Lea wrote:

Hi Cliff,  

 

Could you remind us why Java doesn’t allow tail-recursion optimization?  

 

Thanks!  

-Doug  

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?

Cliff