It won't. I'll explain a little more: A plan has been made to add tail recursion but in a way that, with each recursion, a dummy stack frame is recorded so that a generated exception still looks as if tail recursion didn't happen. Such a mechanism could in theory be made to work endlessly as well, basically by adding a pointer and using an increment, but tail recursion doesn't have to call itself, and a loop doesn't have to follow the same path every time through, so getting that right is rather complicated. If such a loop/count mechanism isn't added, then you're still going to run into the problem that given enough recursions, you get memory problems.
The first part of the plan would be to implement TR but to keep the concept of the growing stack trace. Purely for the modest performance gain. On Sep 25, 8:35 am, Ricky Clarkson <[email protected]> wrote: > > tail recursion is still on the backboiler, it's been discussed many > > times over the last few years and while its nice, it's not deemed all > > that important. For java its useless, as representative stack traces > > are deemed more important than the extremely modest performance gain > > of tail recursion > > Tail recursion is not about performance. Recursive algorithms crash > (StackOverflowError) given enough calls, and that won't happen if they are > tail recursive in a language or VM that supports tail recursion. > > Does the JVM definitely never remove stack frames due to inlining or any > other optimisations? -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
