Distributed garbage collection
DGC uses some combination of the classical garbage collection (GC) techniques, tracing and reference counting. It has to cooperate with local garbage collectors in each process in order to keep global counts, or to globally trace accessibility of data. In general, remote processors do not have to know about internal counting or tracing in a given process, and the relevant information is stored in interfaces associated with each process.
DGC is complex and can be costly and slow in freeing memory. As a cheap way of avoiding DGC algorithms, one can rely on a time lease - set or configured on the remote object; it is the stub's task to periodically renew the lease on the remote object. If the lease has expired, the server process (the process owning the remote object) can safely assume that either the client is no longer interested in the object, or that a network partition or crash obstructed lease renewal, in which case it is "hard luck" for the client if it is in fact still interested. Hence, if there is only a single reference to the remote object on the server representing a remote reference from that client, that reference can be dropped, which will mean that the local garbage collector on the server will garbage-collect the object at some future point in time.
- Abdullahi, Saleh E.; Ringwood, Graem A. (1998). "Garbage collecting the Internet: a survey of distributed garbage collection". ACM Computing Surveys. 30 (3): 330–373. doi:10.1145/292469.292471.