RFR: JDK-8268088: Clarify Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData() [v2]

[Coleen Phillimore]

On Mon, 7 Jun 2021 15:50:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR clarifies Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData(). It adds more explanations on why Method::clear_jmethod_ids only sets the jmethod_ids to NULL without releasing the memory for related JNIMethodBlocks and JNIMethodBlockNodes.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace.
>  - Updated based on Evgeny's comments.

src/hotspot/share/classfile/classLoaderData.cpp line 705:

> 703:   // been derived. After the class is unloaded, the method or field ID becomes
> 704:   // invalid". In real world usages, the native code may rely on jmethod_ids
> 705:   // being NULL after class unloading. Hence, it is unsafe to free the memory

Do we have any use cases of what a real world application can do with a NULL'ed out jmethodID (other than JVM TI will give an JVMTI_ERROR_INVALID_METHODID for it)?
All or most of the JNI functions will crash with a NULL'ed out jmethodID.  You can catch this error by using -Xcheck:jni.  Maybe we could deprecate this feature of the JVMTI spec and release the memory?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4383