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

[Jiangli Zhou]

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 Coleen,

Some more background context related to this:

Users/developers would be happy if we can release memory for jmethod_ids in unloaded cases and get rid of the memory leak. I was pinged recently for the leak after the earlier unsuccessful attempt to fix with https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9 change (on JDK 11, and was rollback due to agent crashes). I haven't found a general solution that would work well without the memory leak.  So decided to clarify the comment for now and also open up the discussion in JDK-8268088.

The agent that ran into crashes with the attempted fix saved stacktraces and jmethod_ids from periodic sampling.  It then tried to get the class and method information (name, etc) from the saved jmethod_ids at later points during the execution and crashed in Method::checked_resolve_jmethod_id with a stale jmethod_id. One possible solution that I thought of was to 'remove' the jmethod_ids in agent during unloading (described in https://bugs.openjdk.java.net/browse/JDK-8268088?focusedCommentId=14424635&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14424635). That could allow deallocating the memory related to those jmethod_ids within the VM. However, that's not a general and efficient solution because:

- It would require a new call back being registered and implemented from the agent. An agent may not choose to do so.  JVM cannot reliably free the memory without a potential SEGV risk with the approach.
- It adds overhead to class unloading. The agent would need to iterate all stored stack traces and find the jmethod_ids related to the classes that are currently being unloaded. That can be expansive and would add noticeable overhead. 
- Also, agent may have bugs and fail to remove a jmethod_ids during the callback.

It would be good if we can find a workable solution for this (for long term).

Thanks!

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

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