Garbage Collector Interfaces and Stub/Skeleton Interfaces

The most of the modern programming languages permit you to allocate memory when a program runs. In Java, memory is allocated with the new operator. Every object that you create with the new operator uses some system resources and the storage may remain allocated longer than it is actually needed. Cleanup is a special problem because it is very easy to forget about an element. Some languages require that the programmer must explicitly release the storage. This approach is error prone, since you might release the storage too soon or forget to release it. Java has a garbage collector that automatically releases memory resources when they are no longer being used.

Garbage collection can be done in a number of ways. Every garbage collection algorithm has some advantages and disadvantages. The RMI system uses a reference counting garbage collection algorithm. The RMI system keeps track of all the live references within each JVM. When a client receives a reference to a remote object, a "referenced" message is sent to the server. When a new reference is created, a reference counter is incremented. When a local reference is finalized, the reference counter is decremented. When the last reference to the object is discarded, an "unreferenced" message is sent to the server. If the remote object has no more live references, the RMI system refers to it using a weak reference. The weak reference allows the garbage collector to discard the object. The distributed garbage collector first interacts with the local garbage collector. If a remote object implements the java.rmi.Unreferenced interface, the unreferenced() method will be called when a set of references are removed. The unreferenced() method may be called more than once. The remote object will be garbage collected when no more live references exist. In case a network fails, an object may be collected prematurely.

The java.rmi.dgc package

The DGC Interface

The DGC interface is used for the server side of the distributed garbage collection algorithm. The interface contains two methods: dirty() and clean(). A dirty call is made whenever a remote reference is retrieved from a marshal stream. A corresponding clean call is made when no more references to the remote object exist in the client. A clean call removes the VM IDs from the reference list for each remote object specified. A remote reference is leased for a period of time by the client holding the reference. The lease period starts when a dirty call is received. The client should renew the lease, by making additional dirty calls, before that lease expires. If the client does not renew the lease before it expires, the system then assumes that the client no longer references the remote object.

 Methods

• public void clean(ObjID[] ids, long seqNum, VMID vmid, boolean strong) - The clean method is called when no more references to the remote reference exist in the client. This method removes the "vmid" from the reference list of each remote object indicated in "ids".

• public Lease dirty(ObjID[] ids, long sequenceNum, Lease lease) - This method is called when a remote reference is unmarshaled in a client. The dirty call requests leases for the remote object.

The Lease Class

A Lease object contains unique virtual machine identifier and lease duration. A Lease object is used to request and grant leases to remote object references.

Methods

• public VMID getVMID() - This method returns the client VMID associated with the lease.

• public long getValue() - This method returns the lease duration.

The VMID Class

The VMID class provides unique identifiers across all Java virtual machines. A VMID may be used to identify client VMs.