Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
jtsk_2.0
-
None
-
None
-
5053556
Description
Bugtraq ID 5053556
The current "DGC client" implementation for net.jini.jeri.BasicObjectEndpoint was closely based on the client-side DGC implementation of J2SE RMI (JRMP); therefore, JDK RFE 5053529 applies to BasicObjectEndpoint as well. Below is the Description of 5053529 slightly edited as necessary for this category.
The current "DGC client" implementation maintains exactly one thread, named "(JSK) RenewClean-[host:port,csf]", per distinct endpoint for which there is a live remote reference to a remote object at that endpoint in the current virtual machine.
In other words, if there are currently live (i.e. reachable, not garbage collected) remote references to remote objects at N different endpoints 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 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 "DGC client" 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.