[foreign+linkToNative] RFR: 8230202: Fix failure of foreign/pthread/Threads.java with linkToNative

[Jorn Vernee]

Yes, this can be pushed.

Jorn

On 03/09/2019 10:29, Nick Gasson wrote:
> Thanks Jorn. Just checking this is ok to push now?
>
> Nick
>
>
> On 27/08/2019 22:32, Jorn Vernee wrote:
>> Hi Nick,
>>
>> The patch looks good to me.
>>
>>   > I'm wondering what the status of linkToNative is at that the moment?
>> Is there a list of missing features/bugs that need to be fixed before it
>> can replace the JNI-based fastpath?
>>
>> Sorry for the radio silence w.r.t. linkToNative. Maurizio is currently
>> away, and we have not really had a chance to discuss the plan going
>> forward. I have my own ideas, but I'd like to wait until he gets back
>> before starting the discussion (since he's the Architect).
>>
>> Cheers,
>> Jorn
>>
>> On 27/08/2019 09:15, Nick Gasson wrote:
>>> Hi,
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230202
>>> Webrev: http://cr.openjdk.java.net/~ngasson/foreign/8230202/webrev.0/
>>>
>>> This patch applies the fix for 8226250 (callback from native 
>>> threads) to
>>> linkToNative.
>>>
>>> In the upcall stub `__ get_thread(...)' calls Thread::current() but 
>>> that
>>> assumes the calling thread is already attached to the VM. Moved the
>>> existing logic to handle attaching to the VM as a daemon in this case
>>> out of the four upcall implementations into a static method in
>>> UniversalUpcallHandler. We can then call this from the linkToNative
>>> upcall stub.
>>>
>>> Also fixed a potential race in Threads.java between the native thread
>>> starting and the VM exiting after main() returns.
>>>
>>> The new calls to in_bytes() are unrelated: just fixing the debug build.
>>>
>>> -- 
>>>
>>> I'm wondering what the status of linkToNative is at that the moment?
>>> Is there a list of missing features/bugs that need to be fixed before
>>> it can replace the JNI-based fastpath?
>>>
>>> Thanks,
>>> Nick