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

Memory Leak in Class Loaders with RMI-IIOP

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P2
    • 1.4.2_10
    • 1.4.2_07
    • other-libs
    • None
    • b01
    • generic
    • windows_2000

    Backports

      Description

        Memory leak in application that is consequence of
        com.sun.corba.se.internal.io.ObjectStreamClass holding static references to classes used as arguments in RMI remote methods.

        According to my understanding, in Java, unless you explicitly create a class loader, the application classes are loaded by the default class loader. We refer to all classes loaded by the default application class loader (as well as the bootstrap classloader) as the default namespace.

        To allow the application to connect to different middle layer releases, several backend namespaces are created (one for each connected middle layer). In other words, a new class loader is created and used to load classes
        that are specific to a certain middle layer release.

        Let's assume that Z1 is a class used as argument for RMI-IIOP remote method invocations. In order to serialize instances of this class, an instance of com.sun.corba.se.internal.io.ObjectStreamClass keeps a
        reference with reflective information about Z1 (more specifically,
        a reference to a java.lang.Class).

        When the backend is no longer necessary (that is, when the client application is disconnected from a certain middle layer), it is disposed. In other words, all references from objects in the default namespace to any object in the backend
        namespace are removed. Additionally, all references to that backend class loader must be removed. When this happens, all classes loaded by that class loader become eligible for garbage collection, freeing space in the
        permanent generation memory space.

        However, although all references from the application classes to any backend object and to the class loader are removed, the classes are not garbage collected. Using OptimizeIt to profile the application memory, it became
        clear that the only remaining references are from the ObjectStreamClass, that belongs to the default namespace. This will prevent the garbage collection of the class loader. Therefore, a new class loader is created each time the client application connects to a middle layer, but the memory used by the previous is never released.


         

        ###@###.### 2005-2-28 07:09:05 GMT

        Attachments

          Issue Links

            Activity

              People

                duke J. Duke
                psreekumsunw Priya Sreekumar (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: