JDK-6823077 : memory leak when making RMI invocation for JMX
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86
  • Submitted: 2009-03-27
  • Updated: 2013-01-04
  • Resolved: 2013-01-04

1. Run the MBeanServer in Linux
2. Register an MBean to the server (Let the MBean method takes a custom object as a parameter)
3. Invoke that MBean from a client using RMI connector

For every invocation, the OrderClassLoader reference is getting leaked .

The leak happens when umarshalling happens in the RMI layer

This bug can be reproduced always.
Submitter writes:

During the unwrapping of the object
The following line is getting executed (From javax.management.remote.rmi.RMIConnectionImpl.java

private static <T> T unwrap(final MarshalledObject mo,
                                final ClassLoader cl1,
                                final ClassLoader cl2,
                                final Class<T> wrappedClass)

// ....
return unwrap(mo, new OrderClassLoaders(cl1, cl2),                                      wrappedClass);


When i profiled .. i found the instances that are created here are not getting garbage collected.. even after full GC.

This happens only in linux... when i tried the same in windows then i am not able to see the references in the profiler ... they are getting garbage collected ...

 The MBean that i registered with the JMX server is taking some custom object
a method like
public void myMethod(MyObject obj)


Not reproducible. Performing the steps given in the problem description I've verified (by a heapwalker) that all the OrderClassLoader instances created during the RMI communication are eligible for GC. Feel free to reopen when you are able to provide a heap dump with the leaked OrderClassLoader instances.

Firstly, it is weird that the java heap instances should be leaking on linux only. Secondly, the OrderClassLoaders instances are used only as temporary thread context class loaders. They don't even become defining class loaders for classes since they delegate all the class loading/defining to the wrapped class loaders. Therefore they are strongly referenced only while being the thread context class loaders and become eligible for GC as soon as the unwrap method is finished. I wonder if it would be possible to get heapdump with the leaked OrderClassLoaders instances. I am not able get any leaked loaders even though I am running the test on Ubuntu Linux.