Hi everybody!
It's been a while since I posted the last update about the continuations
work:
As Christian already mentioned we wrote a paper about the implementation
of the continuation capture/resume functionality. The paper isn't
published yet but I can send private copies to anyone who's interested.
I'll also attend the JVM Language Summit in September.
Apart from the finishing the paper I've been working hard on making the
continuations patch more stable and I've by now created a small
junit-suite which allows me to perform all the refactorings I wanted to
do for such a long time...
The current API is quite simple:
Continuation c = new Continuation();
Object ret = c.save();
if (ret == Continuation.CAPTURED) {
c.resume(null);
}
// ret is null at this point
The next thing on my agenda is delimited continuations. (which also
allows for portable, serializable, etc. continuations, you know, all the
fun stuff...) The challenge here isn't the technical implementation (as
this is already laid out by the underlying implementation) but the
interface. I'd be more than happy about any input you can give me!
As I see it the basic problem is how one can specify the point at which
the continuation is bisected. There are a few options:
* use a (native or non-native) method that takes a Runnable as the border
* specify a method at which to cut the delimited continuation
* allow the application to walk the stackframes of the continuation and
decide where to cut
* use the "difference" between two continuations
* and possibly some more...
For performance reasons there is one restriction: The delimited
continuation should not be cut within a stackframe. This might not seem
like a problem but remember that inline can collapse multiple java
stackframes into a single native one.
So I'd propose the following:
interface DelimitedRunnable {
public void run(Continuation cont);
}
/* Executes runnable and passes the continuation that can be used to
return to return as a parameter. Every continuation stored below this
stackframe is a delimited continuation as soon as control returns to the
delimited method. */
Object delimited(DelimitedRunnable runnable);
/* Appends the delimited continuation to the current stack and starts
execution. The Continuation.copy method returns the continuation that
can be used to return. */
Object delimited(Continuation cont);
usage would look like this:
class Enumerable implements DelimitedRunnable {
private Continuation cont = new Continuation();
public void run(Continuation ret) {
int i = 0;
while (true) {
Object o = cont.save();
if (o == Continuation.CAPTURED)
ret.resume(i);
else
ret = o;
i++;
}
}
public void next() {
if (cont.isEmpty())
Continuation.delimited(this);
else
Continuation.delimited(cont);
}
}
Security: I don't think that delimited continuations make any difference
security-wise.
The current status: I could push the patch into the patch-repository,
but I'm kind of a mercurial-newbie... Do you perhaps have any pointers
to a description of how that works? :-)
- Lukas
Charles Oliver Nutter wrote:
> Ok, I've decided that along with tail calls and indy, the next thing
> on my list is delimited continuations.
>
> Ruby 1.9 has started to make heavier use of "fibers", which are
> basically just coroutines or generators. Not only can you use them
> directly, a la fiber = Fiber.new, you can also get generator behavior
> out of any method on Enumerable. So instead of writing:
>
> foo.each {|a| p a}
>
> you can do
>
> enum = foo.each
> p enum.next
> p enum.next
> ...
>
> This is implemented in CRuby by using coroutines and stack-saving
> techniques. On the JVM, if we can't reduce the enumeration to a simple
> case (like known core classes), or if the iteration is arbitrarily
> complex (as it could be for a user-defined enumerable type), our only
> option is to use a thread. And that will be pretty heavy if people are
> doing a lot of enumeration.
>
> So I need to ask:
>
> What's the status of the continuation patch?
> Who else has interest in it?
> Would delimited continuations reduce security concerns?
>
> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
