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

[kalinshi(施慧)]

Agree!  I also hate hacking.
Currently we’re supporting internal use and will come up with scenario later.  Basically it is  similar with early discussion https://mail.openjdk.java.net/pipermail/loom-dev/2020-May/001307.html.

Regards
Hui

发件人: Ron Pressler <ron.pressler at oracle.com>
发送时间: 2020年11月12日 19:30
收件人: 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)

The problem with hacking into JDK internals is that 1/ they can change without notice in any release (even patches),
and 2/ their uses must satisfy some invariants that we’re careful to preserve, and you might inadvertently break.

So the question is, why is it important for you to share a ThreadLocal among multiple threads?
Instead, what you can do, for example, is pass a map to several threads upon creation.

Also, it is certainly possible that you have a reasonable use-case that we’d like to support safely, but it’s also
possible that you’re doing some premature optimisation and overcomplicating things. Can you explain your use
case for running multiple virtual threads on a specific platform thread and sharing data among them? Have
you run into some specific performance issues or are you trying to preempt performance issues that you
think might exist but haven’t yet run into?

If we can find a way for you to do it with a public API — whether by adding more capabilities or pointing out
a different way for you to do it — then it’s surely better than hacking into internals.

— on


On 12 November 2020 at 10:55:42, kalinshi(施慧) (kalinshi at tencent.com<mailto:kalinshi at tencent.com>) wrote:
Thank! I checked early discussion and the situation is quite same with us.

There are JLA.getCarrierThreadLocal/setCarrierThreadLocal interfaces. They can be access with --add-exports options and access carrier thread’s thread locals..
Will loom keep these interfaces?

Regards
Hui

发件人: Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>>
发送时间: 2020年11月12日 5:00
收件人: 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 11/11/2020 14:14, kalinshi(施慧) wrote:


> 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.

We don't want to expose access to the carrier thread's locals as it could lead to all manner of breakage. There are number of discussion on this topic already in the mail archive,

If you use a custom scheduler, as Ron suggested, then you get a "hook" to run code on the carrier thread before and after the virtual thread task. The hook has a reference to the virtual thread so you may have enough for what you are doing.

-Alan