[gclist] Weak locators in a reference listing DGC

[Pekka P. Pirinen]

Helmut Rubasch <Helmut.Rubasch@jk.uni-linz.ac.at> wrote:
   The easiest scenario I could think of is a 3-node (A,B,C) system with 2
   objects (a and b, both initially on node A), where object a is
   referenced from the local rootset (on A) and b is referenced by a.

   Migrating object a to node B and then to node C also leaves a trace of
   stubs and scions for object b on the nodes B and C.

   The weak locator of object b on node C indicates, that  the original
   b-object is still on node A.

   The problem (?) is, that if you migrate object b from node A to node B,
   a local garbage collection on node A can reclaim the stub/exit-item on
   node A (not referenced by any strong locator), while b's weak locator on
   node C still points to node A

That's where it goes wrong: When object b migrates to node B, the
scion there must continue to be connected to the earlier stub (that
refers to node A).  You can't go around modifying such scions (to
connect directly to object b) then and there, because of the
consistency problem you outline and because it wouldn't make any
difference, anyway, without updating all the weak locators earlier in
the chain.  Luckily, there's no need to, because the connection
doesn't matter until a message is sent from node C to object b.  At
that point, the final scion in the chain (on node B) notices the
chain, and sends a location exception back (because the message has to
be remarshalled, see <URL:http://www-sor.inria.fr/projects/sspc/long/>
section 5 for details).  At this point, the chain is shortcut in the
usual way; Now all the old stubs and scions are garbage, and until
that point, they were all reachable, so it all stays consistent
throughout.
-- 
Pekka P. Pirinen
Adaptive Memory Management Group, Harlequin Limited