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

sun.rmi.transport.GC retains a strong reference to the context class loader

    Details

    • Subcomponent:
    • Resolved In Build:
      b130
    • Verification:
      Not verified

      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 thread created by the GC class does not explicitly set the context
      class loader so it inherits the current context class loader.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Consider the following sequence where each module has a dedicated class loader (e.g. web applications in a Servlet container).

      Module A starts an RMIConnectorServer instance. Amongst other things it
      calls GC.requestLatency(long) which starts the Daemon thread.

      Module B starts another RMIConnectorServer instance. It also calls
      GC.requestLatency(long) and the Daemon thread continues.

      Module A shuts down the RMIConnectorServer and does all the right
      clean-up. The associated LatencyRequest is cancelled but the Daemon
      thread continues because of the LatencyRequest from Module B.

      At this point there is a memory leak because the class loader associated
      with module A is pinned in memory since a reference to it is held by the
      context class loader field of the Daemon thread.

      The fix looks to be trivial. Something along the lines of the following
      around line 146 of GC:

      d.setContextClassLoader(GC.class.getClassLoader());

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      The class loader from module A is eligible for GC.
      ACTUAL -
      The class loader from module A is not eligible for GC.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      https://github.com/markt-asf/memory-leaks/blob/master/src/org/apache/markt/leaks/rmi/GcThreadLeak.java
      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      Trigger the creation of the thread with a thread context class loader than is never going to be eligible for GC.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                chegar Chris Hegarty
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: