Avoid Native Pin when use Continuation direclty with reflection invoke

[Alan Bateman]

On 10/11/2020 12:01, kalinshi(施慧) wrote:
> Hi All,
>
> When use Continuation directly and invokes reflection method then yield, Continuation will be pinned.
> Looking at current NativeMethod/ConstructorAccessorImpl, it only forces java accessor generated and invoke java code when executing in VirtualThread. This still Pin's if directly using Continuation.
> As Pin is a state in Continuation, will it better checking if Continuation is on stack instead of checking VirtualThread? So reflection invoke will not pin/block Continuation/VirtualThread.
>
You might know this already but there is currently no plan to expose an 
API for the underlying continuations construct. The Continuation class 
will move to somewhere in jdk.internal. I mention this to avoid creating 
a dependency that will break once we get to doing some cleanup.

Your patch is okay as a workaround for two cases but there are 150+ 
other places where code using continuations directly may block.

Can you summarize what you are doing as maybe your use-case is something 
that can be done in another way?

-Alan