TCCL memory leak in RMI registry creation

Mark Thomas markt at
Thu Apr 21 13:53:47 UTC 2016

Continuing the previous thread but with a more precise subject.



is sufficient to pin the Thread Context Class Loader (TCCL) in memory
with no public API available (that I can find) to remove the reference.

This is a problem for modular environments like Java EE containers that
can frequently load and unload modules since it will trigger a memory
leak. I have made a simple Java class that demonstrates this issue
available on GitHub. [1]

Up to and including Java 8, it is possible to use reflection tricks [2]
to a) identify these leaks and b) fix them. As of Java 9, these
reflection tricks will be blocked.

Being able to identify and fix these memory leaks has been extremely
useful in resolving issues with memory leaks with multiple deployments
in Java EE environments.

I believe that equivalent functionality needs to be available in Java 9
onwards. I have no strong views on what that functionality should look
like as long as it enables the leaks to be identified and, ideally,

Looking at the source code for sun.rmi.transport.Target, the ccl field
was added for good reason and needs to be retained. That suggests that
the solution is likely to involve destroying a currently existing
registry. While Registry.destroy() (or similar) would be sufficient for
application developers to do the 'right thing' it would not be
sufficient for container developers to identify that an application
running on the container had done the 'wrong thing' and needed to be
fixed. For that something along these lines would be required:


Assuming my analysis is correct, thoughts on the above solution or any
alternative solution welcome. For example, a way to hack around the Java
9 restrictions would be sufficient.





More information about the core-libs-dev mailing list