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

Doerr, Martin martin.doerr at sap.com
Wed Aug 7 14:48:13 UTC 2019


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



More information about the hotspot-runtime-dev mailing list