Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8268088

Clarify Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData()



    • Enhancement
    • Status: Resolved
    • P4
    • Resolution: Fixed
    • 11, 17
    • 17
    • hotspot
    • b26


      Our developers noticed a memory leak with Method::ensure_jmethod_ids for a longer running application. The allocated JNIMethodBlockNodes are not freed after the associated user defined class loaders are unloaded. The daily leak is ~20MiB - ~70MiB. Please see the initial discussion in https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-January/044946.html. The following comments in
      https://github.com/openjdk/jdk/blob/379376f0783facba93e1d11db9b184ef8183a13b/src/hotspot/share/classfile/classLoaderData.cpp#L697 indicate the leak is 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.

      Our attempted fix (https://github.com/openjdk/jdk/commit/66ef04af110862a1a6b727f12ad5eed9c26cd5a9) ran into SEGV crash in production environment when a profiler agent was enabled. The agent captured stack traces and then symbolized methods using jmethod_ids at a later point during runtime execution, which could happen after unloading the associated classes and loaders.

      Further investigations have not yet found a more suitable approach than the existing one in Hotspot, which sets jmethod_ids to NULL instead of freeing the related memory during unloading. The existing approach mostly like was selected when considering the trade-off among stability, complexity and memory usage (although no additional background information has been located).

      This bug is created to further clarify the comments in ClassLoaderData::~ClassLoaderData() for Method::clear_jmethod_ids() to explain why it is unsafe to release jmethod_id memory.


        Issue Links



              jiangli Jiangli Zhou
              jiangli Jiangli Zhou
              0 Vote for this issue
              5 Start watching this issue