coroutines once more...

[Jim Baker]

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 the Python space to
infrastructure like Stackless Python or greenlets. In both cases, these
solutions avoid the expense of stacks for each coro. In particular, the
greenlet stack manipulation sounds quite similar.

- Jim

On Thu, Dec 3, 2009 at 2:46 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

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



-- 
Jim Baker
jbaker at zyasoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091203/1f634e8c/attachment.html