coroutines once more...

[Attila Szegedi]

As coroutines are often employed in situations where massive parallelism is desired, I believe that the approach that allows millions of them is the better choice, if a single choice has to be made.

That said, if there is a meaningful way to have the programmer choose between the two models (or, in a really advanced solution, have the HotSpot choose for you), and  it's not a hassle to maintain both, then it's probably the best. As you said, it's a tradeoff, and it's certainly better to allow the developer to make the tradeoff choices for themselves.

Attila.

On 2009.12.01., at 17:11, Lukas Stadler wrote:

> Hi everybody!
> 
> I would be very interested to hear what the expectations for a coroutine 
> implementations for Java are. I am asking because I am facing some 
> initial design decisions on my way.
> 
> There is a quite simple tradeoff between memory/address space usage and 
> execution speed:
> * Using "traditional" implementations context switches are very cheap 
> (constant time), but at least 12-16 kb of memory and 16-32 kb of address 
> space is used per coroutine. This can exhaust 32-bit address space with 
> ~50000 coroutines. And in order to do something useful we might need 
> larger stack sizes, which lowers this number even further. A coroutine 
> might need a larger stack size even though it occupies only a fraction 
> of it while it is suspended. Creating and removing coroutines is expensive.
> * A more space-preserving implementation only keeps the parts of the 
> coroutine in memory that it actually uses. It will be able to handle 
> millions of coroutines, but this comes at the cost of a more complex 
> context switch. Creating and removing coroutines is very cheap this way.
> 
> For small coroutine it might be prohibitively expensive to allocate a 
> real stack, but other applications might benefit from the fast context 
> switch. Maybe I should aim for a hybrid solution?
> Any thoughts?
> 
> regards,
> Lukas
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev