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

[David Holmes]

On 18/07/2021 11:51 pm, Sebastian Stenzel wrote:
> On Fri, 16 Jul 2021 15:59:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
> 
>> For a complete description of the issue, please refer to:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8270851
>>
>> This patch makes the logic for detaching native threads more lazy - by only doing the detach when a native thread has completed. This is achieved by using some thread local storage, which is used to keep track of the Java thread associated to a given native thread. If, by the time the thread local storage is destroyed, we see that a Java thread has been attached, we do a detach operation. This trick effectively minimizes the number of Thread instances created when interacting with multi-threaded native code.
>>
>> This patch also tweaks the logic for attaching native threads to the VM by using the "daemon" attach variant. That is, native threads registered against the VM (because of Panama upcalls) should not prevent the JVM to shut down in an orderly fashion (in cases where the native threads might outlive the JVM).
> 
> Is switching to daemon threads required for this fix to work? When dealing with non-daemon native threads, will the JVM wait for it to _terminate_ or to _detach_, before it shuts down?

For a non-daemon the JVM will remain alive as long as it is attached. So 
if it only detaches at termination then the JVM will wait till it 
terminates.

There may also be a problem with using a thread-local to control 
detaching. The panama code is using the C++11 thread_local which we do 
not use in the VM. As the C++ thread_local relates to C++ threads and 
their lifecycle, it is not at all clear to me how it operates for 
threads that may not use the C++ thread API ie when will the object 
actually be destroyed? Detaching a thread also uses the compiler native 
thread-local mechanism, as well as the library based mechanisms. Luckily 
if these things run in the wrong order (but don't otherwise interfere) 
they will actually appear detached before detach is called, and the call 
to detach is a no-op in that case.

David

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