United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6233622 : Memory Leak in Class Loaders with RMI-IIOP

Details
Type:
Bug
Submit Date:
2005-02-28
Status:
Resolved
Updated Date:
2010-02-23
Project Name:
JDK
Resolved Date:
2005-07-26
Component:
other-libs
OS:
windows_2000
Sub-Component:
corba:idl
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_07
Fixed Versions:
1.4.2_10 (b01)

Related Reports
Backport:
Backport:

Sub Tasks

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

                                    

Comments
EVALUATION

This problem is well known and already fixed in the master CORBA
workspace.  However, this fix has not yet been propagated to
the Tiger update release or Mustang workspaces.  This bug will
be fixed for the next CORBA integration in Mustang.
###@###.### 2005-2-28 17:07:09 GMT
                                     
2005-02-28



Hardware and Software, Engineered to Work Together