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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
