The current client-side DGC implementation maintains exactly one thread, named "RMI RenewClean-[host:port,csf]", per distinct remote endpoint for which there is a live remote reference to a remote object at that endpoint in the current virtual machine. Remote endpoints (for J2SE RMI/JRMP) are distinguished by their values of host string, TCP port integer, and (optionally) client socket factory object.

In other words, if there are currently live (i.e. reachable, not garbage collected) remote references to remote objects at N different endpoints (combinations of host, port, and client socket factory) in a given VM, there will also be N "RenewClean" threads, one for each such endpoint, in that VM.

The benefit of this current design is that it provides clean isolation of the client-side DGC-related activities for each distinct remote endpoint, which is the logical grouping of such activity-- which includes batched dirty and clean calls to the endpoint's server-side DGC, retry logic for such remote calls, and tracking reachability (through phantom reference notifications) of all live remote references to the endpoint. Because remote calls are made as part of this activity, it is essential that delays in making a remote call to one endpoint do not interfere with client-side DGC activity for any other endpoint.

The problem of the current design is that when N is very high, such as because a VM has live references to remote objects on hundreds or thousands of different hosts, the sheer number of "RenewClean" threads becomes excessive.[*] Each of these threads spends most of its time simply waiting on a ReferenceQueue for unreachability notifications, so the amount of actual concurrency needed (even for making remote dirty/clean calls) is far less than N.

The client-side DGC implementation should be re-implemented with an improved concurrency model. All phantom references could be registered with a single ReferenceQueue, and a single thread could be used to wait for notifications on that queue. All other client-side DGC activities could be scheduled to execute at a given time/delay on a thread pool that can expand and contract as necessary to provide the necessary concurrency.


[*] Another cause for excessive "RenewClean" threads is improper (or lack of) overriding of Object.hashCode/equals in an RMIClientSocketFactory implementation, as described in this bug report:

http://developer.java.sun.com/developer/bugParade/bugs/4492317.html

but that cause should be fixed in the user RMIClientSocketFactory implementation code.