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

[Jorn Vernee]

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