Review Request JDK-8188052: JNI_FindClass needs to specify the class loading context used for library lifecycle hooks

David Holmes david.holmes at oracle.com
Thu Oct 5 00:44:32 UTC 2017


Hi Mandy,

On 5/10/2017 4:12 AM, mandy chung wrote:
> This patch separates the JNI `FindClass` issue from the review thread 
> for JDK-8188052 [1] into a different issue.
> 
> webrev: 
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.00/index.html 

src/hotspot/share/prims/jni.cpp

Okay ... so by nulling fromClass in the classloader during finalization 
(soon to be moved to the Cleaner) you can now distinguish between the 
OnLoad case and the OnUnload case, within FindClass - a comment to 
clarify that would be good, please.

However you still have:

  407     if (loader.is_null() &&

but you deleted the initialization of loader:

- 404     loader = Handle(THREAD, k->class_loader());

so it will by default be null. I suppose checking the loader is only a 
potential optimization as the name of the class will be uniquely 
determined anyway. But the code should be cleaned up.

---

Otherwise all seems fine.

Thanks,
David

> 
> This patch changes `FindClass` to specify the class loading context used 
> for the load and unload hook. `FindClass` when called from JNI_OnUnload 
> is changed to use the system class loader as the context. This is an 
> incompatible behavioral change and this bumps the version so that a 
> native library can determine the new behavior if desire.  This change 
> proposes to defines JNI_VERSION_10 and I expect this name will be 
> revisited along with the version string for the proposed new release 
> cadence [2].
> 
> CSR:  https://bugs.openjdk.java.net/browse/JDK-8188069
> 
> Thanks David for the suggested spec wordings.
> 
> thanks
> Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049292.html 
> 
> [2] 
> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html


More information about the hotspot-runtime-dev mailing list