RFR(XS): 8229236: CriticalJNINatives: dll handling should be done in native thread state

[David Holmes]

Hi Martin,

On 8/08/2019 12:48 am, Doerr, Martin wrote:
> Hi,
> 
> we noticed that we execute OS functions to deal with dlls (e.g. dlopen, dlsym) during lookup of critical JNI functions (CriticalJNINatives). These functions need to perform I/O which may be slow.
> The current implementation executes these functions while the thread is in state "_thread_in_vm". This means that the thread blocks safepoints while performing I/O.
> In order to reduce safepoint delays, I/O should be executed while the thread is in state "_thread_in_native" which avoids blocking safepoints.
> 
> Adding ThreadToNativeFromVM seems to be trivial, but there's one issue with that:
> We're holding AdapterHandlerLibrary_lock and the constructor of ThreadToNativeFromVM asserts that we're not holding any locks.
> I think we could allow that because code running at safepoint doesn't care about this lock.

I'm unclear why the prohibition on leaving the VM while holding a lock 
exists. From a safepoint perspective I see no difference in going from 
VM to blocked (on a different lock) and going from VM to native. In both 
cases the thread holding the lock is in a safepoint-safe state.

That said, changing that rule should be a last resort and as Dean stated 
we really don't want to make special cases here. Either no lock should 
be held or any lock can be held.

Further, doing I/O while holding a lock seems like a bad idea anyway, so 
if this call can be done before the lock is acquired as Dean suggested, 
I think that would be a much better solution.

Thanks,
David
-----

> Is this ok or is there any better idea?
> 
> So here's my current proposal:
> http://cr.openjdk.java.net/~mdoerr/8229236_critNat_resolution/webrev.00/
> 
> Please review.
> 
> Best regards,
> Martin
>