On Friday 25 April 2008 12:06:28 Attila Szegedi wrote: > On 2008.04.24., at 20:41, Jon Harrop wrote: > > Tail calls has to be the single biggest omission. There are others > > like > > first-class functions and custom value types. > > The more I think about it the more I am certain that I would not want > JVM to have an explicit tail call bytecode instruction (I'm not saying > anyone said that; I'm thinking out loud). If javac can figure it out, > then a JIT can figure it out too. Tail calls should be just another > code transformation managed by the JIT compiler; it could be deferred > until StackOverflowError occurs, then walk the stack, remove tail > calling frames from it, and maybe recompile the code of those frames' > methods to use tail calls immediately next time. A program or library > written in recursive fashion would need to declare that it "must be > run on a tail-call optimizing JVM for problem sets that are not > trivially small" and that's it. > > Anyone disagrees? > > Of course, this doesn't change the sad fact that we don't have such a > tail-call optimizing JVM today...
The 64-bit implementations of the CLR do TCO at a lower level as you suggest. However, you have not mentioned the things that make TCO difficult on these kinds of VM: keeping the run-time happy and not breaking security. You may be interested in these posts: http://blogs.msdn.com/shrib/archive/2005/01/25/360370.aspx http://blogs.msdn.com/davbr/pages/tail-call-jit-conditions.aspx -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" 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/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
