On Wednesday 23 April 2008 18:05:27 Steven Shaw wrote: > 2008/4/24 Steven Shaw <[EMAIL PROTECTED]>: > > So it works if you do a CPS transformation on all your code leaving > > your frames on the heap.
Yes. > > In that case you can tail call a continuation > > to simulate the exception. Exactly. > > I am interested in this approach. You may like the book "Compiling with continuations" by Appel. > > I like > > the flexibility that CPS style gives (perhaps different exception > > models to the norm). However, wouldn't this approach have other > > performance consequences (mainly the heap-based frames)? Yes. Current CPS implementations are typically ~50% slower for ordinary code but there are lots of non-trivial trade-offs involved and lots of interesting optimization potential elsewhere. One important benefit is that moving stack frames onto the heap eliminates stack overflows, simplifies the run-time (no stack to crawl!) and can improve incrementality because the stack is often crawled atomically. You also get callcc for free, which can be extremely useful in some circumstances. On the other hand, the stack is often used for implicit thread-local storage with concurrent GCs as an optimization and pushing everything onto the heap burdens the GC. I believe CPS also complicates FFI. > What I'm getting at is if CPS transformation and tailcalls were so > performant for exceptions then why bake exceptions into the CIL and > into the JVM bytecodes? I believe there are two main reasons: . Debugging: exceptions provide a lot of trace information. Without a stack, you don't even get a stack trace with CPS. . Business: industry value the old far more than they value the new and they want to see minimal overhead added to old techniques. This was seen before in C++: "you don't pay for what you don't use". The JVM and the CLR were designed for business and largely adopted this mentality as a consequence. Don't forget that, when they were introduced, many users feared garbage collection let alone tail calls! Microsoft have put considerable effort into features not found on the JVM, like efficient tail calls, not only supporting them but even continuing to aggressively optimize them. > I really appreciate Scheme because it provides > the primitives to implement high-level constructs like exceptions (and > coroutines, backtracking) but I figured because the "big guys" in > runtime systems baked in particular exception systems then it wasn't > considered fast enough for this common case. I believe the designs of the JVM and (to a lesser extent) the CLR were much more backward looking than forward thinking because that is essential for commercial success. Had the same effort been put into the best theoretical design then I'm sure we could have had something much more productive (but totally incompatible). -- 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 -~----------~----~----~----~------~----~------~--~---
