RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

[Doug Simon]

On Mon, 9 Nov 2020 11:50:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
>> 
>>> 97:   if (thread == NULL) {
>>> 98:     JavaVM_ *vm = (JavaVM *)(&main_vm);
>>> 99:     vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, NULL);
>> 
>> Style nit: don't put spaces around `->` operator.
>> 
>> What is the context for this being called? It looks highly suspicious to just attach the current thread to the VM this way.
>
> The context is a thread that is spawned by native code doing an upcall. We need to attach the thread to the VM first in that case. Normally this would be handled by the calling code, but in our case the calling code doesn't know it's calling into Java.

Where's the logic for the native thread to detach? We have a similar problem in libgraal. We have a [utility class](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L27-L32) for libgraal created threads (as opposed to VM created threads that call into libgraal) that call into the VM. The utility class takes care of [attaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L749) and [detaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L757) to/from the VM.

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

PR: https://git.openjdk.java.net/jdk/pull/634