If a buggy or (mildly) malicious RMI server endpoint implementation caused a
RuntimeException instance to be thrown as a result of a DGC dirty() or clean()
call, then the thread in the client VM that made the DGC call will terminate
(in our implementation), preventing any further lease renewals or clean calls
to be made to that server endpoint from the client VM (all current and future
leases will expire after their current or initial duration).

This possibility is new with JDK 1.2, in which unchecked RuntimeException can
be thrown directly from remote method calls; in JDK1.1, they would have been
wrapped in instances of ServerRuntimeException, which would have been caught
when RemoteExcetpions were caught.

The client-side DGC threads might as well try to be more robust by catching
(and ignoring) RuntimeExceptions that are thrown by remote server DGC objects,
although with the JDK 1.2 FCS client-side DGC implementation, there is a
separate thread to handle lease renewals and clean calls for each remote
endpoint, so effects would only be limited to DGC with the ill-behaved endpoint,
unlike with previous versions' implementations.