=?utf-8?Q?=E5=9B=9E=E5=A4=8D=3A_?=Avoid Native Pin when use Continuation direclty with reflection invoke(Internet mail)

[Ron Pressler]

Continuations will not be usable directly. They are now in the Early Access, but the class will be removed.
If you do use them directly, the compiler may fail to compile them correctly, and you will see very strange bugs. The JIT compiler 
currently assumes that continuations are only used by virtual threads, and performs optimisations based on that assumption.

For your code to behave correctly and be prepared for Loom’s release, you should replace your use of continuations 
with virtual threads, possibly with a custom scheduler.

As for your need to declare data to be local (with ThreadLocal) and then share it globally, can you explain what it is that you’re
trying to do?

— Ron


On 11 November 2020 at 03:36:07, kalinshi(施慧) (kalinshi at tencent.com) wrote:


We plan to use continuation directly to build server application. Make group of continuations running on a single thread. This simplifies resources contention.  
Some considerations to use Continuation directly  
1. Continuation is enough in our scenario. Not want to pay overhead in virtual thread.  
2. Easy to use Thread Local shared resources between all continuations running on same thread. Access carrier thread's ThreadLocal in virtual thread is unnatural (Please correct me if wrong).  

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

Agree, continuation will still blocked in LockSupport.park/IO currently only checks VirtualThread.  
In my own understanding : ）， there are two kinds of modifications to reduce "block" in Loom  
1. make Continuation yield when"Thread" is blocked: LockSupport/IO changes etc. These block "Threads" conceptually, so is natural to check if virtual thread is on stack executing.  
2. make Continuation not pinned when yield happen: like replace object monitor(runtime lock) with LockSupport based lock; reduce JNI frames. Pin is a concept on Continuation, checking if continuation is running is more natural.  

Regards  
Hui  

-----邮件原件-----  
发件人: Alan Bateman <Alan.Bateman at oracle.com>  
发送时间: 2020年11月10日 20:56  
收件人: kalinshi(施慧) <kalinshi at tencent.com>; loom-dev at openjdk.java.net  
主题: Re: Avoid Native Pin when use Continuation direclty with reflection invoke(Internet mail)  

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