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