Coro in Java 8

[Lukas Stadler]

I totally agree as well, naturally :-)

And I do plan on spending more time on the coroutine patch again, I 
didn't do much coding in the last months because I was occupied at 
university.
The result of this is my thesis on coroutines: 
http://ssw.jku.at/Research/Papers/Stadler11Master/

The coroutines in the current state actually provide full stack 
reification and can simulate continuations, albeit with suboptimal 
performance.
But this is confined to two concrete methods (serialize/deserialize), 
and can thus easily be restricted with permissions.

I would be really interested to hear what you guys think are the most 
important characteristics for coroutines... since an implementation is 
always a tradeoff:
* fast creation
* fast 1st activation (the first time a coroutine gets to run)
* fast switching
* fast migration from thread to thread
* many coroutines (~100)
* lots of coroutines (~ 10000)
* lots and lots of coroutines (~ 1000000)

I'll soon fork of a version that only supports lots of coroutines, 
because this makes a lot of things much easier (it doesn't require the 
whole copy to/from stack logic).

And I also think that a jsr as a rallying point would help a lot - I'll 
see what it will take to create one.

cheers,
  Lukas


Am 2011-04-27 20:33, schrieb Charles Oliver Nutter:
> I think it's time to start talking about what we'd need to do to get
> coroutines in Java 8.
>
> In the absence of forking, lightweight processes, or M:N threading,
> there's no efficient way to implement a large set of problems that
> demand fiber/coroutine-like behavior. Add to that the fact that
> languages like Ruby and Erlang already want for "fibers", and in JRuby
> and Erjang we have to hack around the JVM to support them.
>
> With the narrowing of Lucas's patch to downstream coroutines (rather
> than unbounded continuations) I believe most of the concerns about
> security have been addressed. Or at least, enough of those concerns
> have been addressed that we need to get this patch in front of more
> people to find new concerns.
>
> So, I guess what's needed would be at least a JSR, which then needs
> someone to lead it (I don't think we'd have much trouble getting
> people to participate).
>
> Any thoughts on trying to push coro through to Java 8 as an official
> feature? I'm convinced it needs to happen.
>
> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev