[Pharo-project] why OOP needs tails recursion article
We recently had a discussion on tail-call optimization at the SCG. In one of my Pharo image I counted 160464 send locations, of which only 8884 would allow for tail call optimization (5.5%). Tail call optimization could certainly be implemented at the VM level, but I don't know if the additional checks and complexity would be worth the effort for these few locations? VM experts might be able to tell more ... Also I think it would be rather confusing to debug a tail-call optimized program in the debugger (random stack frames would be missing). Lukas 2009/12/5 Stéphane Ducasse <stephane.ducasse@inria.fr>:
http://lambda-the-ultimate.org/node/3702
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
2009/12/5 Lukas Renggli <renggli@gmail.com>:
We recently had a discussion on tail-call optimization at the SCG. In one of my Pharo image I counted 160464 send locations, of which only 8884 would allow for tail call optimization (5.5%).
Tail call optimization could certainly be implemented at the VM level, but I don't know if the additional checks and complexity would be worth the effort for these few locations? VM experts might be able to tell more ...
Also I think it would be rather confusing to debug a tail-call optimized program in the debugger (random stack frames would be missing).
I am also looking suspiciously on such kind of optimization for smalltalk, because it could make debugging harder as well as breaking a reflection, since you can't be sure that 'thisContext sender' is one that actually made a call. In languages with lower reflection bar, such optimization could be employed, but in smalltalk, i doubt.
Lukas
-- Best regards, Igor Stasenko AKA sig.
participants (3)
-
Igor Stasenko -
Lukas Renggli -
Stéphane Ducasse