回复: Avoid Native Pin when use Continuation direclty with reflection invoke(Internet mail)

[kalinshi(施慧)]

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