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

Coleen Phillimore coleenp at openjdk.java.net
Tue Jun 8 13:38:20 UTC 2021


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.

Hi, I put a short comment in JDK-8268088 which I'll expand later.  There's already a JVMTI callback for unloading classes that the user could use to walk the saved jmethodID stacks:

  // notify the debugger
  if (JvmtiExport::should_post_class_unload()) {
    JvmtiExport::post_class_unload(ik);
  }

Otherwise, don't change class  unloading to add a callback because it could be sensitive to safepoints and unsafe places.

My comment in this bug echoes what Ioi said above.  To prevent class unloading, the class mirror should be saved with the Method.  This is the approach taken throughout the vm.  I think hunting down applications that need to fix their profilers may be difficult, but we could add some deprecation messages and warnings (or even an option, which I thought was what you were going to do).  I'm not sure why so many lines are changed in your above pull request.

For now the updated message seems fine to me for JDK 17.

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

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


More information about the hotspot-runtime-dev mailing list