On Wed, 11 Nov 2020 13:31:11 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> 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 Ok. That makes for high overhead for each upcall on a non-attached native thread. I assume that's an edge case not worth optimizing? ------------- PR: https://git.openjdk.java.net/jdk/pull/634
