ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted

[Stephan B]

Thank you for your insight. I'm aware that the thread is pinned and must be pinned while executing native code. However it would be great to have a JNI native API to unmount the thread while waiting for data and to mount again to an available carrier thread once data arrived. I guess however that this will never happen.

I hope you will decide to expose more to give more flexibility to interact with native code. I know that there is a lot of discussion about how much to expose and how much to guard the programmer. Even though most developers will not need such flexibility I still believe it is vital to support it so that great products can be built which interact with native code. The JVM is so brillant and it would be a pity if it got too restricted. It makes me also a bit worried about what is going to happen to sun.misc.Unsafe as we use it heavily for memory IO. I hope it will stay and coexists with the new Foreign-Memory Access API.

- Stephan


> On 7 Jan 2023, at 22:37, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230108/bea6643b/attachment.htm>