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

[Jiangli Zhou]

On Mon, 7 Jun 2021 18:43:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> 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?
>
> This comment looks like an expanded version of the one I wrote a long time ago and correct.  We were wondering if this is a feature that we actually need.

> 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?

The JVMTI agent use case that ran into issues (with releasing memory) calls GetMethodDeclaringClass for a stale jmethod_id (with unloaded class and loader) and crashes in Method::checked_resolve_jmethod_id when it's dereferencing the 'mid'.

The agent native code does check for JVMTI_ERROR_NONE after calling GetMethodDeclaringClass in this case, but it's too late.

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

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