Right now I'm getting two failed patches when trying guards="buildable callcc". The first is applying callcc to hotspot:
applying callcc.patch patching file src/cpu/x86/vm/templateInterpreter_x86_32.cpp Hunk #1 succeeded at 160 with fuzz 1 (offset -8 lines). patching file src/share/vm/classfile/vmSymbols.hpp Hunk #1 FAILED at 347 1 out of 6 hunks FAILED -- saving rejects to file src/share/vm/classfile/vmSymbols.hpp.rej The second is applying indy.tests.patch to jdk: applying indy.tests.patch patching file test/java/dyn/MethodHandlesTest.java Hunk #2 FAILED at 110 1 out of 16 hunks FAILED -- saving rejects to file test/java/dyn/MethodHandlesTest.java.rej I'm going to try callcc alone against bsd-port head. On Thu, Nov 12, 2009 at 11:56 AM, Charles Oliver Nutter <[email protected]> wrote: > Hot diggity! > > On Thu, Nov 12, 2009 at 11:08 AM, Lukas Stadler <[email protected]> wrote: >> Hi everybody! >> >> I've just checked in the first prototype of a coroutine implementation. >> It's implemented using the continuations framework, so it's not very >> speedy (~1µs per context switch in a simple example) but it allows me to >> experiment on how the API for coroutines could look like. >> This is how it currently works: >> >> public class CoroutineTest extends Coroutine { >> public CoroutineTest(CoroutineContext context) { >> super(context); >> } >> >> public static void main(String[] args) { >> CoroutineContext context = new CoroutineContext(); >> new CoroutineTest(context); >> new CoroutineTest(context); >> context.start(null); >> } >> >> �...@continuable >> protected Object run(Object value) { >> for (int i = 0; i < 10; i++) { >> System.out.println(i); >> yield(null); >> } >> return null; >> } >> } > > Looks pretty clean to me! I assume there's an equivalent "resume" > called from outside to pick up where the previous yield left off, yes? > >> The Coroutine class is very similar to the thread class, it can either >> be subclassed or provided with a CoRunnable object. >> The main concept is that every coroutine is associated with a >> CoroutineContext when it is created. The coroutines will start to >> execute as soon as CoroutineContext.start is called and this method will >> not return unless all coroutines have finished. The coroutines are kept >> in a doubly-linked ring and the default scheduling (which can be changed >> by subclassing CoroutineContext) always just yields to the next >> coroutine in the ring. > > Interesting. I guess I don't know this use case for coroutines. The > cases I need would (I believe) all be isolated CoroutineContexts that > may or may not call against each other. > >> The main drawback of using a coroutine context in this way is of course >> that coroutines are tied to a specific thread - is this a problem? A >> notion of "moving" a coroutine from one context (and thread) to another >> could be introduced, but a coroutine will always need to be associated >> with a context so that we can make sure it will end properly. >> I'd be glad to hear what you guys think of this! > > I'm excited to try it out! Tying to a specific thread should not be a > problem for me...I forgot what the outcome of our long coroutine > discussion was, but if I remember correctly tying to a thread was > considered one of the safer (if more limited) ways to go. And in > JRuby, there should be no cases where we need to use coroutines across > threads since Ruby itself won't do that. > > Does the patch apply and build and all right now? I could try playing > with it today. > > - Charlie > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
