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

[Maurizio Cimadamore]

On 18/06/2019 17:43, Henry Jen wrote:
>> On Jun 18, 2019, at 4:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> Fixed aarch64 problems and pushed.
>>
>> Henry, I tried to address your comment, but CPP complains if I just replace JavaVM_ with JavaVM. I also noted that the same pattern is spread everywhere in hotspot, so I figured it was 'ok’.
>>
> Did you change the way you make calls?

I left everything as it was yesterday (module aarch64 fix), in the end.

Maurizio

> I think there is a bug in jni.h,
>
> typedef JavaVM_ JavaVM;
>
> should be
>
> typedef struct JavaVM_ JavaVM;
>
>
> Cheers,
> Henry
>
>> Of course if somebody knows a better way to do this, we can update the code.
>>
>> Cheers
>> Maurizio
>>
>> On 17/06/2019 18:14, 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
>>>