ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted
Alan Bateman
Alan.Bateman at oracle.com
Sat Jan 7 21:37:44 UTC 2023
On 07/01/2023 18:31, Stephan B wrote:
> Hi loom dev team
>
> The project I work on involves a great deal of native code where thread interaction between java and native code is vital.
> Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure.
>
> Like the following code illustrates
>
> var runtime = Runtime.current();
> unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr);
> unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr());
>
> Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific).
>
> This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread.
>
> Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored.
> ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable).
> There should be a way to access the native thread and to store state on that.
So far, the main issue we have with native code is that a virtual thread
is pinned to its carrier when executing native methods. If you are
blocking in native code, or calling through native frames back to Java
and blocking, then it may not be too scalable.
On thread-specific data (pthread_getspecific, etc.) then there isn't any
supported way to change that at scheduling points. We did have prototype
support for "custom schedulers" in early access builds for a long time
that did provide the before/after hooks that could be used to do this.
It's not something that most developers will every interact with
directly but we do hope to explore the area further to decide what might
be exposed.
-Alan
More information about the loom-dev
mailing list