.. moving to serviceability - maybe you can help me. Thanks! Thomas
---------- Forwarded message --------- From: Thomas Stüfe <thomas.stu...@gmail.com> Date: Wed, Nov 7, 2018, 11:38 Subject: JNIMethodBlockNode leak question To: Hotspot dev runtime <hotspot-runtime-...@openjdk.java.net> Hi all, I wonder whether I understand this correctly: When a caller requests a jmethodId bei either calling jni-GetMethodId() or jvmti-GetClassMethods(), the returned jmethodId is a pointer into a slot of a table containing the respective Method* pointers. That table is tied to the ClassLoaderData. When the classloader is unloaded and its ClassLoaderData deleted, we do not delete that table, but rather deliberately leak it after zeroing it out. The reason - if I understand the comment in ~ClassLoaderData correctly - is that jmethodId live forever - a caller may hand it in long after the class has been unloaded, and this should be handled gracefully. We cannot simply delete its JNIMethodBlockNode, since the jmethodId then would either point to unmapped memory - which we could handle with SafeFetch - but worse could point to memory reused for a different purpose. We also could not reuse that slot, since then that jmethodId would point to a different method? Apart from the fact that we would need infrastructure for that, a global pool of JNIMethodBlockNode, with associated locking etc. Have I understood this correctly or am I off somewhere? And if I am right, that would mean that were we to generate classes over and over again in new class loaders and accessing their methods with JNI, we would have a slowly growing leak, even if we clean up the loaders? Thanks, Thomas
