When a dirty call is successfully made to indicate that a local implementation
has a live reference in a client, it is not guaranteed that the weak reference
to the implementation in the object table is "pinned" (temporarily made into a
strong reference) at that time. Thus, it is possible that the weak reference
will get cleared by the VM (if there are no local strong refs to the impl), and
when the "Reaper" thread goes to remove the cleared reference to the collected
impl, it detects the invariant breach that it does know of a client VM with a
live ref to that remote object, so it throws a java.lang.Error indicating an
internal error.

In designs that have been most typical so far, this situation will not occur,
because the weak ref to an exported remote object does get pinned when a copy
of the live (remote) ref to the object is serialized over an RMI connection,
i.e., as a parameter or return value of an RMI call. Usually, this is how a
client gets remote references, so the above situation will not occur.

This can occur in a case where all of the following conditions occur:
- A client VM obtains a live ref to the impl through means other than an RMI
  call, e.g., if the stub is serialized to an HTTP accessible file, and the
  client deserializes the stub from a HTTP URL connection.
- The server VM does not keep any strong local refs to the impl (which is an
  application bug if it expecting the impl to not get collected and it isn't
  known that there are live refs in other client VMs; but this application bug
  still should not bring about the RMI internal error).
- [Because of delays in weak reference implementation's clearing behavior,] the
  impl does not get collected until some client VM deserialize a copy of the
  stub, and it is able to successfully execute a dirty call on the object;
  subsequently, enough memory allocation requests occur to cause the VM to
  finally clear the associated weak reference (incorrectly, since it should
  have been pinned by the dirty call). At this point, the reaper will soon
  notice the invariant breach and throw the Error.

This was demonstrated by bugid 4066643.