Continuation.yield limitations

[Remi Forax]

----- Mail original -----
> De: "Ron Pressler" <ron.pressler at oracle.com>
> À: "Arkadiusz Gasiński" <jigga at jigga.pl>, "loom-dev" <loom-dev at openjdk.java.net>
> Envoyé: Vendredi 6 Septembre 2019 13:01:00
> Objet: Re: Continuation.yield limitations

> 1. Because monitors are built into the VM to be owned by threads. Moving them
> between threads,
> then, requires changing how they’re implemented, and that’s a significant amount
> of work.
> We want to do that eventually, but it’s not currently supported.
> 
> 2. Unlike monitors, which are a temporary limitation, this one is here to stay.
> Native stack frames could contain pointers into the stack without the VM knowing
> about them.
> This makes copying and moving continuation stacks around hard without some
> clever virtual
> memory tricks that would diminish our flexibility in implementing continuations.
> Given
> that this limitation does not seem to cause much pain, we might as well make it
> permanent.

the other non-solution is to patch all stack addresses when moving the continuation, the problem is that there is no way to know if a value on a C stack is a stack address or not.

> 
> 
> Ron

Rémi

> 
> 
> 
> On 4 September 2019 at 21:51:35, Arkadiusz Gasiński
> (jigga at jigga.pl(mailto:jigga at jigga.pl)) wrote:
> 
>> Hi,
>>  
>> Could someone here try to ELI5 the current limitations of
>> Continuation.yield method? Specifically, why we can't yield when:
>>  
>> 1. the body of the continuation holds a native monitor
>> 2. a native method is on continuation's stack
>>  
>> Thanks,
> > Arek