On 2009.04.02., at 19:15, Ola Bini wrote: > No one is doing hand rolled stacks.
Rhino is, in interpreted mode. In addition to having stack continuations support thanks to this, it also gives it automatic tail call support. If you set interpreted mode *and* disable emitting debug info, then all tail calls (not only those to the same function, but to any function) will eliminate the caller stack frame before invoking the callee. (It's safer to discard the caller frame and create a new one for the callee than to reuse the caller frame, as the tail call can happen as part of a catch block that's unwinding because of an exception that left the caller frame in a corrupted state - admittedly a low-likelihood corner case, but still it's good being defensive...). Note that you need both a) interpreted mode and b) no debug info for this to work. In compiled mode, Rhino compiles to Java bytecode and uses the Java stack, so neither continuations nor tail calls stack frame elimination work. When debug info is enabled, it's possible to attach a debugger to the running scripts using Rhino debug API, and TCO would confuse the API contract. Actually, that's something that I think could be fixed... > Clojure does explicit trampolining - > but that is a very coarse and limited way of doing it. Scala removes > tail calls where it can be statically transformed into iteration, but > doesn't give any guarantees. Ruby has never had TCO's and JRuby uses > the > Java stack too. > > SISC is one of the few implementations that do full TCO. There are > basically a few variations on how to do it. CPS is common, > trampolining > works too. You can also have your own bytecode engine with your own > stack. Yep, that's what Rhino does in interpreted mode. > The overhead of all of these approaches are pretty severe on the JVM That is true. I doubt anyone would use interpreted mode just for TCO. Pretty much the only justifications for it are If you need continuations, or you can't generate Java classes on the fly. Attila. > since the usage pattern is data driven and far away from how regular > Java code looks like. But the most severe problem with it is that > all of > these approaches make it much hard to do calls into Java methods. > > Cheers > >> >> On Thu, Apr 2, 2009 at 9:59 AM, kirk <kirk.pepperd...@gmail.com >> <mailto:kirk.pepperd...@gmail.com>> wrote: >> >> >> John Cowan wrote: >>> On Thu, Apr 2, 2009 at 10:36 AM, kirk <kirk.pepperd...@gmail.com >> <mailto:kirk.pepperd...@gmail.com>> wrote: >>> >>>> why do they have to be exposed? Isn't tail recursion and >> implementation >>>> detail? And an optimization at that? >>>> >>> >>> No. >>> >>> Being able to rely on tail recursion is not an implementation >> detail; >>> Scheme programmers routinely write programs that tail-call >> heavily and >>> would blow up without it. A state machine implementation where >> state >>> transition codelets, expressed as functions, are tail-called by the >>> dispatcher and tail-call it in turn is a classic example. "Lambda: >>> the ultimate goto." >>> >> Understood, that said I think Patrick hit the nail on the head. >>> And since Java exposes the call stack via Exception#fillInStack, the >>> *presence* of tail recursion is unfortunately not an implementation >>> detail either. >>> >> I would humbly disagree with this last statement. >> >> Regards, >> Kirk >> >> >> >> >> >>> > > > -- > Ola Bini (http://olabini.com) > Ioke creator (http://ioke.org) > JRuby Core Developer (http://jruby.org) > Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) > Practical JRuby on Rails (http://apress.com/book/view/9781590598818) > > "Yields falsehood when quined" yields falsehood when quined. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
