Potential memory leak in Method::ensure_jmethod_ids

[Jiangli Zhou]

Hi,

Developers reported a potential memory leak in Method::ensure_jmethod_ids
for a longer running application on JDK 11 (most likely the memory leak
exists in newer JDK versions as well). The allocated JNIMethodBlockNodes
are never freed, which is the case even for user defined class loaders
after unloading. The daily leak is ~20MiB - ~70MiB. Although the memory
leak is not very large, it's still good to eliminate it.

The following comment in ClassLoaderData::~ClassLoaderData()
<https://github.com/openjdk/jdk/blob/764111ff831096729eb1bcc69a54d92fde67b044/src/hotspot/share/classfile/classLoaderData.cpp#L705>
indicates it's intentional:

// 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.
if (_jmethod_ids != NULL) {
  Method::clear_jmethod_ids(this);
}


The change was introduced as part of the large permgen removal effort. It's
not too clear what are the side-effects (related to JVMTI agent?) of
deallocating the JNIMethodBlockNodes after unloading. Does anyone know if
there was a specific bug related?

Thanks!

Best,
Jiangli