[foreign-memaccess+abi] RFR: 8270851: Logic for attaching/detaching native threads could be improved

[Maurizio Cimadamore]

On Fri, 23 Jul 2021 05:44:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>  don't recall what the panama programming model is in regard to application use of native threads and the use of upcalls, but perhaps for the case at hand when threads are making many upcalls and the attach/detach overhead is significant, then the application should be responsible for attaching and later detaching these threads, with the upcall mechanism checking for an already attached thread?

The main issue with putting developers in charge of deciding when/how to attach/detach is that, unlike with JNI, where user code runs (albeit in C/C++) before/after the upcall (so we have a chance to attach/detach things), in Panama the code doing the upcall is some unknowing piece of native code calling a function pointer. There's nothing we can inject in the library code, of course, as that code is fixed - so the only thing we can change is what happens when the upcall starts/finishes.

I have few questions for you though.

1. What happens if an attached thread is never deattached?
2. We can imagine we have an API for attaching threads, exposed by CLinker:


boolean attachThread(Thread t, boolean daemon, ResourceScope)


This will attach a thread (if needed) to the JVM (either in daemon mode, or normal), and will register that onto a ResourceScope, meaning that when the ResourceScope is closed, the thread will be deattached.

This API is not impossible to do - what I'd like to understand is what happens if we jump into the upcall code _before_ we have attached the thread to the JVM. Is that a correctness issue? If not, we could go down that path - but if a native thread can _never ever_ execute a single line of Java code before being attached to the VM, well, that creates a chicken and egg problem, I think.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/570