Yes, the best will be to have the choice, i.e two different Java objects or a way to select if you want to share the stack between coroutine or not.
Rémi Attila Szegedi a écrit : > 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 > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
