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

JVMTI hides critical debug information for memory leak tracing

    Details

    • Subcomponent:
    • Resolved In Build:
      b126
    • CPU:
      x86
    • OS:
      windows_2008

      Description

      FULL PRODUCT VERSION :
      java version "1.8.0_92"
      Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
      Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows [Version 6.1.7601]

      A DESCRIPTION OF THE PROBLEM :
      The fix for https://bugs.openjdk.java.net/browse/JDK-4496456 completely hid the java.lang.Throwable.backtrace field from the JVMTI API. This creates problems for tools such as YourKit that use the the JVMTI since it prevents an entire class of memory leaks from being diagnosed.

      https://bugs.openjdk.java.net/browse/JDK-8146961 is a memory leak (actually two memory leaks) in the XML processing caused by the use of static fields of type RuntimeException. If initialization of these fields is triggered by a class loaded by a temporary / disposable class loader (such as a web application class loader in a JavaEE environment), a reference chain is created that pins the class loader in memory. Because of the fix applied for https://bugs.openjdk.java.net/browse/JDK-4496456 it is impossible to trace the GC roots for this leak.

      This reference chain passes through the Throwable.backtrace field because of the reference it holds to the class (and its class loader) that triggered the initialization. Because the backtrace field is hidden from JVMTI, YourKit (and other profilers like Eclipse MAT) is unable to identify the GC root. This makes it next to impossible to diagnose the root cause of the memory leak.

      More generally, any memory leak triggered by the use of a static exception field is going to suffer from the same problem and be very difficult to diagnose.


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Reproduce memory leak as per https://bugs.openjdk.java.net/browse/JDK-8146961 and then use a JVMTI based profiler to trace the GC roots for the leaking class loader.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      The GC root should be traceable via Throwable.backtrace.
      ACTUAL -
      No GC root is visible.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      CUSTOMER SUBMITTED WORKAROUND :
      YourKit supports an alternative, but limited in functionality, format for memory snapshots. If the HPROF format is used the GC root is visible.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                coleenp Coleen Phillimore
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: