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

[dean.long at oracle.com]

Hi Martin.  Making an exception for this code makes me a little 
nervous.  It looks like with a little refactoring the problem could go 
way: move the call to method->critical_native_function() up into 
AdapterHandlerLibrary::create_native_wrapper() before the lock is entered.

dl


On 8/7/19 7: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.
> 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
>