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

[Nick Gasson]

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