There are a couple of places in the current J2SE RMI implementation where tasks get scheduled for delayed execution by creating a separate thread that spends most of its life waiting for the (next) time when its task should be executed. This can result in more threads being created than are necessary for the concurrency requirements of these tasks.

One example is the "ConnectionExpiration-" reaper thread created per TCPChannel (i.e. per set of outgoing connections to the same TCPEndpoint) for detecting idle connections whose idle timeout has expired. [Up to] one thread per TCPChannel seems excessive for this activity, especially given that each reaper thread terminates itself when the number of idle connections for the channel becomes zero (and thus might need to be recreated after subsequent remote calls over the channel). Another example is the "LeaseChecker" thread created by the server-side DGC implementation, although it is only (at most) one thread per VM, and it is unlikely to be terminated and restarted as often, so it less of a concern. Another example (sort of) are the "RenewClean-" threads created by the client-side DGC implementation; that issue is already covered by another RFE (see 5053529), but it seems that the solution for that RFE could share code with the solution for this RFE (as well as with the solutions for 5026942 and the last part of 5054828).

It would seem desirable for the RMI implementation to employ a central utility for scheduling delayed execution of its internal tasks, thus reducing the thread overhead of such scheduling. The java.util.Timer API is unsuitable for this purpose because it does not support specifying a factory for creating the thread(s) it uses for executing tasks (see 5026942). An alternate utility that does not have this limitation appears to be java.util.concurrent.ScheduledThreadPoolExecutor. Note that it still might be necessary to dispatch these tasks in a growable thread pool to achieve the needed concurrency, for tasks that could block because they invoke user code (such as because of custom socket factories), make remote calls, etc.