hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization
lukas.stadler at jku.at
Thu Dec 23 07:09:21 PST 2010
Maybe I should say a few words about what I did...
First of all I changed a few details of how the coroutine stacks are
walked during gc, which should make the coroutine code more reliable.
Other than that, there are three new methods in CoroutineSupport:
* public boolean stealCoroutine(CoroutineBase coroutine)
This method can be used to "steal" a coroutine from another thread. It
seemed the most natural to me that the thread that the coroutine should
be transferred to initiates the transfer, that way a thread that is idle
can "steal" a coroutine. (this took a little inspiration from the
The transfer can fail for a number of reasons, e.g. if the coroutine is
currently running or if the current thread already owns the coroutine.
"stupid" things like trying to steal from the current thread will throw
an exception, otherwise the success is reported as the boolean return value.
* public CoroutineFrame serializeCoroutine(CoroutineBase coroutine)
Returns the java frames of the specified coroutine as an array of
CoroutineFrame. This is a rough prototype of how this should work, the
returned frames include frames that an application should not be able to
for (CoroutineFrame frame:
* public void replaceCoroutine(CoroutineBase coroutine, CoroutineFrame
Replaces the given coroutine's contents with the given frames. There is
no checking of the given stackframes whatsoever!
The serialization/deserialization could be used to replace an
interpreter loop with a compiled method, kind of Java-OSR - that would
On 21.12.2010 17:18, lukas.stadler at jku.at wrote:
> Changeset: b7b61c41e164
> Author: Lukas Stadler<lukas.stadler at jku.at>
> Date: 2010-12-21 17:18 +0100
> URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b7b61c41e164
> coro: experimental coroutine thread migration and serialization
> ! coro.patch
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the mlvm-dev