Memory leak in sun.rmi.transport.GC

[Mark Thomas]

While working my way through Tomcat's memory leak protection / detection
/ fixing code, I have found an issue that remains unresolved in the
latest JDK 9 source.

The thread created by the GC class does not explicitly set the context
class loader so it inherits the current context class loader. Consider
the following sequence where each module has a dedicated class loader
(e.g. web applications in a Servlet container).

Module A starts an RMIConnectorServer instance. Amongst other things it
calls GC.requestLatency(long) which starts the Daemon thread.

Module B starts another RMIConnectorServer instance. It also calls
GC.requestLatency(long) and the Daemon thread continues.

Module A shuts down the RMIConnectorServer and does all the right
clean-up. The associated LatencyRequest is cancelled but the Daemon
thread continues because of the LatencyRequest from Module B.

At this point there is a memory leak because the class loader associated
with module A is pinned in memory since a reference to it is held by the
context class loader field of the Daemon thread.

The fix looks to be trivial. Something along the lines of the following
around line 146 of GC:

d.setContextClassLoader(GC.class.getClassLoader());


It may appear contrived but I have seen exactly this memory leak occur
in production systems where multiple web applications were using RMI.

If I can provide any further information or if there is better place /
way to submit this then please do let me know.

Mark