hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization
forax at univ-mlv.fr
Thu Dec 23 11:52:01 PST 2010
On 12/23/2010 04:09 PM, Lukas Stadler wrote:
> 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
> fork/join framework...)
> 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
> be neat...
clearly neat :)
I want to do the opposite i.e. generate a compiled code that
bailout to an interpreter if by example a + overflow.
How can I read the CoroutineFrame object to reconstitute the stack ?
More information about the mlvm-dev