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

[kalinshi(施慧)]

Thanks for you clarification, Ron!
What specific JIT optimization will cause using Continuation out of VirtualThread has strange bugs?

> 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?
For ThreadLocal on carrier thread, we want all VirtualThreads running on it can access and update this carrier thread’s ThreadLocal.
This carrier ThreadLocal can hold shared configurations/stats/resources used by all VirtualThreads running on same carrier thread.
It’s not suppose “share it globally,” share it between all VirtualThreads on same carrier thread.

Regards
Hui

发件人: Ron Pressler <ron.pressler at oracle.com>
发送时间: 2020年11月11日 17:40
收件人: kalinshi(施慧) <kalinshi at tencent.com>; Alan Bateman <alan.bateman at oracle.com>; loom-dev at openjdk.java.net
主题: Re: 回复: Avoid Native Pin when use Continuation direclty with reflection invoke(Internet mail)

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<mailto: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<mailto:Alan.Bateman at oracle.com>>
发送时间: 2020年11月10日 20:56
收件人: kalinshi(施慧) <kalinshi at tencent.com<mailto:kalinshi at tencent.com>>; loom-dev at openjdk.java.net<mailto: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