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 > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
