In current 1.2.x and 1.3 implementations, the RMI runtime may strongly refer to a remote object even after it has been explicitly unexported.

After a remote object has been explicitly unexported, the RMI runtime's DGC implementation should no longer prevent it from being garbage collected locally. With the current implementation, however, if a remote (client) VM is known to be holding a valid lease to the remote object before it has been unexported, the DGC implementation will continue to strongly reference the remote object as long as that client's lease remains valid (i.e. until the client drops all of its references, or is detected crashed due to lease expiration).

A customer's heap analysis shows a chain of strong references in the following entities from a GC root to a remote objects of type "MyRemoteImpl" even after the remote object has been unexported:

<root> ->
  DGCImpl static "dgc" ->
    DGCImpl "leaseTable" ->
      Hashtable ->
        Hashtable$Entry[] ->
          Hashtable$Entry ->
            DGCImpl$LeaseInfo "notifyList" ->
              Vector ->
                Object[] ->
                  Target "weakImpl" ->
                    WeakRef "strongRef" ->
                      MyRemoteImpl

First, when a Target is unexported, it does not unregister itself from receiving notifications for each client VMID in its "referenced set". These registrations constitute strong references to the Target object, from the Vector in the notifyList field of the entries in the DGCImpl's leaseTable.

Second, when a Target is unexported, it also does not "unpin" its weak reference to the remote object, even though there is no longer any reason for the weak reference to be pinned by the runtime anymore. Normally, the Target object should itself be garbage collected, so the pinned reference shouldn't be a problem, but if a client VMID still holds a valid lease to the remote object, the Target object will be kept around because of the above notification registration.

The combination of both of the above conditions cause the complete chain that keeps the remote object referenced; breaking either condition should prevent the bug. In addition, breaking the first condition should also prevent unused Target objects from staying reachable indefinitely.