Continuations, here I come

[Attila Szegedi]

On 2009.08.08., at 0:03, Hiroshi Yamauchi wrote:

> Hi all,
>
> I'm also curious to see/try the latest update/patch as I'd like to
> experiment with the continuation feature in the JVM.
>
> I have looked at this file (which I think is an old file) so far:
>
> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/2c1323e05f9a/callcc.patch
>
> I patched it to openjdk6 (Hotspot 11) and the test appears to work,
> though the monitor support seemed unfinished.
>
> BTW, here are two comments that I personally had about the API from
> the perspective of using continuations from the Java language
> (referring to the old patch):
>
> 1. I think that we don't want to run the finally clauses twice (once
> when the exception is thrown on 'copyStack' and again after the stack
> is resumed).

The thing is, the semantics of the finally block become application- 
specific when you throw in continuations in the mix. Some finally  
blocks are meant to clean up high-level application state (and thus  
need to only be executed on the very last time). Some finally blocks  
are meant to clean up transient state (i.e. a database connection) and  
should execute every time, plus need some mechanism for  
reestablishment of their state on resume; you yourself mention one  
typical example, which is locking of monitors.

A good continuations mechanism should support both, and add language  
construct for distinguishing between the two. Now, this is not as  
daunting as it might sound. Since - as I said - the nature of the  
finally block becomes application-specific, you can just have an  
application-specific mechanism for checking whether it is a capture or  
the real exit, so you can do:

try {
...
}
finally {
    if(isCapturingContinuation()) {
        ... capturing cleanup (usually unused) ...
    }
    else {
        ... final cleanup ...
    }
    ... transient cleanup ...
}

Those finally blocks that don't have this will be considered to have  
purely transient cleanup, of course. However, a support for  
reinitialization of transient state is naturally required.

> 2. I think we want to unlock all the monitors on a stack save and
> relock them on a stack resume. (though I'm not sure what the intention
> of the unfinished code was.)

Sure, that makes sense. Locks are typical transient state. You get  
unlocking for free if you decide to run the finally clauses on both  
continuation capture and final exit.

Attila.

--
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com