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

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

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 11, 17
    • Fix Version/s: 17
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b26

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              jiangli Jiangli Zhou
              Reporter:
              jiangli Jiangli Zhou
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: