On Mon, 9 Nov 2020 11:50:54 GMT, Jorn Vernee <jver...@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
