JDK-6233622 : Memory Leak in Class Loaders with RMI-IIOP
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:idl
  • Affected Version: 1.4.2_07
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: generic
  • Submitted: 2005-02-28
  • Updated: 2010-02-23
  • Resolved: 2005-07-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_10 b01Fixed 6-poolResolved
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
28-02-2005