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

[Jorn Vernee]

On Mon, 28 Mar 2022 17:03:09 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).
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix whitespaces
>  - Merge branch 'foreign-memaccess+abi' into upcall_lazy_detach
>  - Merge branch 'foreign-memaccess+abi' into upcall_lazy_detach
>  - Remove whitespaces, fix indent
>  - Lazily deattach native threads using thread local storage destructors

src/hotspot/share/prims/universalUpcallHandler.cpp line 63:

> 61: // modelled after JavaCallWrapper::JavaCallWrapper
> 62: JavaThread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
> 63:   JavaThread* thread = maybe_attach_and_get_thread(&context->should_detach);

I think the `should_detach` field can now be removed from `OptimizedEntryBlob::FrameData`

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

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