Normally, each VM generates its own VMID instances to identify itself as a
client of DGC. If, when a VM's VMID is calculated (the first time that it is
needed), the curent access control context does not have permission to resolve
the local host address (necessary for universal uniqueness), then no VMID is
generated and instead, when a DGC dirty() call is made to a remote server,
"null" is passed as the client's VMID, indicating that the server should
assign a VMID to the client VM, which the client would use always in the
future.

This mechanism was intended to facilitate the use of unique client VMIDs for old
RMI applets in the old prebeta and 1.1 days, when applet code was not allowed to
get the local host name/address, or at any rate, applets were supposed to be
able to cause their local host address to be known through any means, such as
coercing the RMI runtime to divulge the address to a remote server's DGC
implementation. (The latter restriction is still true: applets aren't supposed
to be able to obtain the IP address of the machine on which they are executing,
even if trusted library code is now able to execute a doPrivileged() to obtain
it reliably. Of course, the same issue arises when assigning the endpoint
address of exported objects, but that is a fairly separate aspect of RMI and
will not be connected to in this report.)

This mechanism for obtaining a VMID from a remote server, however, relied on
DGC dirty() calls to all remote endpoints to be made synchronously across the
client's VM, so that two or more dirty calls do not start concurrently, each
requestiong a VMID form a different server, and when they return, they compete
for which assigned VMID will actually get used in the future. In previous
client-side DGC implementations, all DGC dirty() calls were globally
synchronized, so this was not a problem; with JDK 1.2 FCS, however, the
client-side DGC implementation has been restructured and optimized so that
dirty() calls do not require global synchronization, so the assigned VMID
race can occur.