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
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
Changeset: 761081d6e5a8
Author:twisti
Date: 2009-12-03 11:53 +0100
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/761081d6e5a8
indy.compiler.inline: Review changes, round 2.
! indy.compiler.inline.patch
___
mlvm-dev mailing list
Support millions of coroutines.
So if it's possible to have a choice, that sounds great, but if not, choose
a more scalable implementation if only one can be done. Making coroutines
effectively as cheap as other objects for managing state opens up their
usage, and it would also be competitive in
Changeset: 101f44f31522
Author:twisti
Date: 2009-12-03 07:23 -0800
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/101f44f31522
indy.compiler.inline: Build fix.
! indy.compiler.inline.patch
___
mlvm-dev mailing list
Changeset: 74b2b52ed9cf
Author:twisti
Date: 2009-12-03 07:37 -0800
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/74b2b52ed9cf
indy.compiler.inline: Missed a hg qref.
! indy.compiler.inline.patch
___
mlvm-dev mailing list
