On Wed, 11 Nov 2020 13:25:32 GMT, Doug Simon <dnsi...@openjdk.org> wrote:
>> 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. I added a call to DetachCurrentThread here: https://github.com/openjdk/jdk/pull/634/commits/719224ca9dc70fce6d28885acfb362fee715ebbd#diff-c084afc373a6ce95010a480ddc5ab79d3cb759b80e46102c212c2cbc948e2303R65 ------------- PR: https://git.openjdk.java.net/jdk/pull/634
