8268088: Clarify Method::clear_jmethod_ids() related comments in Clas…

…sLoaderData::~ClassLoaderData()

Reviewed-by: iklam

src/hotspot/share/classfile/classLoaderData.cpp

@@ -694,12 +694,17 @@ ClassLoaderData::~ClassLoaderData() {
     _metaspace = NULL;
     delete m;
   }
-  // Clear all the JNI handles for methods
-  // These aren't deallocated and are going to look like a leak, but that's
-  // needed because we can't really get rid of jmethodIDs because we don't
-  // know when native code is going to stop using them.  The spec says that
-  // they're "invalid" but existing programs likely rely on their being
-  // NULL after class unloading.
+  // Method::clear_jmethod_ids only sets the jmethod_ids to NULL without
+  // releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
+  // This is done intentionally because native code (e.g. JVMTI agent) holding
+  // jmethod_ids may access them after the associated classes and class loader
+  // are unloaded. The Java Native Interface Specification says "method ID
+  // does not prevent the VM from unloading the class from which the ID has
+  // been derived. After the class is unloaded, the method or field ID becomes
+  // invalid". In real world usages, the native code may rely on jmethod_ids
+  // being NULL after class unloading. Hence, it is unsafe to free the memory
+  // from the VM side without knowing when native code is going to stop using
+  // them.
   if (_jmethod_ids != NULL) {
     Method::clear_jmethod_ids(this);
   }