Coro in Java 8

[Lukas Stadler]

Am 2011-04-28 15:00, schrieb Mark Roos:
> Of course I  would love to see the low level infrastructure in jdk7 
> binaries.
Well, that would be cool, but I think the scope for JDK7 is very much 
fixed by now, and it's a much too short timeframe anyway...
> My thought was to use coroutines to emulate Smalltalk processes.  For 
> this I need to convert the
> machine stack to objects, inspect and manipulate them from the 
> Smaltalk side and then covert them
> back,  Does the above statement mean that this feature is going away?
No, "copy to/from stack logic" refers to internal implementation 
details, it won't change any of the APIs.


Am 2011-04-28 16:33, schrieb Charles Oliver Nutter:
> How would you feel about leading a JSR? :)
Yeah, right :-)
I'll talk to John about how we can approach this. He's probably the one 
with the sudo access.
> Man, you need to get that patch working so I can play with it again :)
> JRuby 1.7 is going to be my "experimenting with Java 7 and beyond)
> release, so I'm keen to get back into coro experimentation (and tailc,
> if that patch could get updated too).
HotSpot has been quite the moving target lately, but I guess that most 
of the big changes are over by now. So I'll see to it that it integrates 
with the other patches again...
> Ouch. I think coroutines must be GCable and not act as a GC root.
Well, it's actually not that simple. There needs to be some kind of test 
to see if a coroutine can just be thrown away, which basically amounts 
to "does the coroutine terminate immediately if I send it a 
CoroutineDeath exception?". This means that a coroutine that has 
finallys or catches that handle this exception needs to be kept around, 
normally until the end of the thread.
> On the other hand, I talked with Jim Baker (Jython) about the
> potential for using "lots and lots" of coroutines, one per
> (language-level, not Java-level) method invocation, to do a poor-man's
> stackless language implementation. In that case we'd need as many
> coroutines as there are active method invocations on the stack, which
> could easily be tens of thousands. This is, again, a rather weird and
> specialized case.
Yes, and to reach the level of performance required for this the 
coroutine implementation would need to be much more intrusive.
> * fast 1st activation (the first time a coroutine gets to run)
> How much of a difference are we talking in the best and worst cases?
The first activation is currently ~100x more expensive than subsequent 
switches, because some data structures need to be set up. This can 
certainly be improved upon.
> And I officially offer my help in making a JSR happen (as much as my
> time permits, of course).
Thanks!

Am 2011-04-28 18:41, schrieb Rémi Forax:
> Also because coroutine can be used to implement concurrent web server,
> there is also a need for a memory model/concurrency guy.
Definitely... although I hope to get by with "well, coroutines are just 
threads that decided to only get scheduled at certain points, aren't they?".
> By coroutine, I mean thread sticky coroutine, thread migration can be
> added later, the most important thing is to have lots of coroutines i.e
> pausable/resumable task with fast micro-scheduling.
One question that remains for me is if coroutine migration should be 
explicit (that how it's implemented now), or implicit...
> Lukas, if you refresh your patch, we can come at the next JVM Summit in
> July with a web server that use co-routine with nio/asyncio plus some
> examples of yield/iterator/generator.
That would be nice ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110429/275ba133/attachment.html