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

Doug Simon dnsimon at openjdk.java.net
Wed Nov 11 13:28:03 UTC 2020


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



More information about the security-dev mailing list