« Will Continuations... | Main | Achieving Closure »
Friday May 19, 2006

Continuations, continued

First, let me correct an important omission in my previous post. The example I gave is closely based on one I was shown by Shriram Krishnamurthi. Shriram is part of the PLT Scheme group. They have done a lot of good work in this area, and in programming languages in general. They even have their own continuation-based web server.

The history of ideas is very important, especially in academia. I'd encourage anyone interested in the topic to look at the above sites, read the papers, and trace back through the citations to understand it all better. As far as I know, the first realization of such a web server was by Paul Graham, but this is not an academic paper and I haven't done a literature search.

As for the substance of the comments on the last post. It seems that most people who responded are comfortable with us not supporting continuations on the JVM. For those who aren't, I have to stress that any feature we add comes at the expense of something else. Resources are finite. If we add X, we cannot do a good job on Y. So we prioritize. We do this based on input from the community, and on our own technical understanding of the cost/benefit ratio of a given feature. Your priorities may differ.

There are still some smart people that don't buy my view continuation based web servers are a temporary expedient. That's fine. Time will tell.

Posted at 03:32PM May 19, 2006 by gbracha in Java  |  Comments[8]

Comments:

"It seems that most people who responded are comfortable with us not supporting continuations on the JVM."

I strongly suspect that most of us who think more favourably of continuation based web servers try to avoid programming in Java. For myself, I don't think that they are the last word in web technology, but I expect that they are going to be the next step in the evolution of web technology.

Posted by John Dougan on May 19, 2006 at 04:40 PM PDT #

Not embracing the needs of scripting language implementers like JRuby is a bad decision for the future of the java platform. Support for continuations etc. is necessary for implementing many high-performing feature complete scripting languages running under the jvm - which in turn is vital for the continued health and growth of the java platform for the next 10 years.

Posted by Morten Christensen on May 20, 2006 at 04:33 AM PDT #

While watching this discussion (with some personal interest - but that's another story), I noticed that advocates cite many examples of the use of continuations - all interesting but not individually compelling. I would point out that support for continuations isn't just a nice-to-have feature. Continuations are a transformational technology for a language. It's very presence supports other models of computation (abstractions) that can be used to solve difficult problems in a way that appears to be magical. Most of what we've seen in Java improvements are tactical. Generics are great; the implementation is powerful. But it's just an improvement. Continuation support transforms how you solve problems. That's a strategic change that will have long-term affects.

Posted by Jerry Boetje on May 20, 2006 at 12:22 PM PDT #

I would argue that continuations are not required, but if added would allow for growth in the solution space of developers that is only seen in languages like, Scheme, Lisp, Smalltalk and other fully dynamic languages. It is interesting to see it expressed that it would be "hard" to add to the JVM without affecting the security context. I find this troubling as the continuation would have context to the security context it was created in.... so why is this an issue? Additionally, I find it troubling that a VM such as Sqeaks can perform very well and be extended to support continuations inside the language itself even though the VM doesn't support it directly and we talk about how it's too hard for us to add the the JVM. This speaks ot the power of the byte-code system of the Squeak VM I guess. Additionally, the JVM and HotSpot should be able to perform well with continuations added as well. The ParcPlace(now Cincom) VM competes with the HotSpot JVM in performance and can support continuations as well as resumable exceptions and fully hotswappable classes and methods amongst other things. In the end I'd like to have full lexical closures, resumable exceptions, mixins, macros and the ability to optionally declare types much like I can do in Lisp/CLOS. Let type inferencing figure out type safety, the load system has all the type info about interfaces and classes it needs to provide warnings and load errors. If not continuations, please at least closures/blocks.

Posted by Sam Griffith on May 22, 2006 at 12:32 AM PDT #

"It seems that most people who responded are comfortable with us not supporting continuations on the JVM."

I strongly suspect you weren't couting right. Then again, as a former commenter said, maybe we just don't belong here, in your Java world. We'd realy like our Scheme (or our Ruby) to belong to your JVM world but, in the end, it'll always be the Java-VM world - not “good” enough for Java, not good enough period.

Posted by ncruces on May 22, 2006 at 04:31 AM PDT #

(Just thinking out loud; this post likely contains utterly terrible ideas. You have been warned.)

Jetty6 implements a feature it calls "continuations," which are really (as far as I can tell) just lots of suspended threads on the server.

Using threads as a sort of poor man's continuation actually does just fine in many cases -- it's possible, for example, to get basic "yield"-style coroutine semantics with some fairly simple abstraction. But in the web server scenario, I can't imagine it's a good idea to keep all those threads around, even if they're all waiting.

I wonder if it's possible to create some sort of mechanism for the long-term suspension of threads that doesn't consume OS resources? Is it possible to detach the actual OS thread from a JVM stack, and reattach it later?

Perhaps it is even possible to do this while maintaining existing thread semantics, and make it transparent: if thread overhead is becoming large, the thread that's been stuck on wait() longest gets tossed to the side. Then you don't have security issues, and don't have to add language features -- the web scenario is still quite possible given a few good abstractions, only now it's just a JVM optimization problem instead of a language problem.

Or maybe the JVM already does this sort of thing, and I shouldn't be afraid of creating thousands of mostly-suspended threads?

Posted by Paul Cantrell on May 22, 2006 at 07:53 AM PDT #

I was incorrect in my earlier comment: Jetty's "continuations" are actually some abort-and-rety hackery which gives the limited appearance of continuations. See the under the "How it works" heading: http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html It seems rather generous to call what they're doing "continuations" at all. People do seem to have had some limited success with it, though.

Posted by Paul Cantrell on May 22, 2006 at 11:28 AM PDT #

JVM Continuations prediction market

Posted by Predictor on May 23, 2006 at 07:40 AM PDT #

Post a Comment:
Comments are closed for this entry.