coroutines once more...

[Rémi Forax]

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
>