[foreign] RFR 8226250: Calling callback from different native threads causes a VM crash

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Jun 18 10:47:56 UTC 2019


On 18/06/2019 02:27, Samuel Audet wrote:
> Hi, Maurizio,
>
> What about just leaving the choice up to the user? It works fine in 
> JavaCPP:
> https://github.com/bytedeco/javacpp/issues/143#issuecomment-262138799
Hi Samuel,

I think in the long run having some -D option to control the behavior 
would be the best option, yes.

But I'd like to wait for linkToNative to be merged into foreign, so that 
we go through the woes of saving registers/restoring only once (since 
that impl should work across all architectures).

In the short term, I think attaching daemon threads is good enough.

Thanks
Maurizio

>
> Samuel
>
> On 6/18/19 2:14 AM, Maurizio Cimadamore wrote:
>> Hi,
>> Under JNI, it is user responsibility to attach native threads to the 
>> VM using attachCurrentThread/detachCurrentThread.
>>
>> Panama doesn't do this and, as a result, if native code creates a new 
>> thread and uses it to call a Java callback, an hard crash occurs.
>>
>> This patch adds a call to AttachCurrentThreadAsDaemon before calling 
>> the Java callback, only if the native thread has no associated Java 
>> thread.
>>
>> The AttachCurrentThreadAsDaemon allows the VM to be shutdown w/o 
>> waiting for native threads to complete, which is, I think the 
>> semantics we want.
>>
>> We don't call the dual detach method for two reasons:
>>
>> * re-attaching the same thread over and over can be expensive
>>
>> * calling detach after the callback means that we'd lose some 
>> register values, so we would additional save/restore
>>
>> Overall, it seems like the 'leak' of JavaThread is not worth the 
>> extra complexity?
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8226250_v2/
>>
>> Maurizio
>>
>


More information about the panama-dev mailing list