Distributed Garbage Collection for Network Objects Presented by Olga Convey Systems Research Center © Digital Equipment Corporation Algorithm by Andrew Birrell David Evers Greg Nelson Susan Owicki Edward Wobber

2 Algorithm Overview  Generalization of reference counting and reference listing: keeps track of processes referencing object  No global synchronization necessary: pair-wise process communication  Distributed garbage collection utilizes local garbage collection

3 Algorithm Advantages  Practical to implement in Distributed Systems: suitable for a wide range of applications  Balances functionality and performance  Fault-tolerant: Communication failures Process failures Reclaims space from crashed processes  Efficient with low cost overhead: only cost is RPC for the 1 st reference transfer

4 Terms and Definitions  Object – consists of a data object and methods that operate on that object  Network object – is the object shared in DS  Owner – process that allocated the network object  Client – process referencing the object  Concrete object – instance of the object the owner process allocated  Surrogate object – contains methods that invoke RPC to the owner, where methods of the concrete object are invoked.

5 Data Structures w(O) Object table Surrogate Object for O Process Q Client of O w(O) Object table O.dirtySet={Q, …} Concrete Object (O) Process P Owner of O can be a weak reference, or NULL PQ

6 Study #1: Reference Counting 1.Client: calls dirty to the owner 2.Owner: adds client’s ID to O.dirtySet 3.Client:creates surrogate 4.Client:local GC determines when O is no longer used 5.Client:call clean to delete surrogate 6.Owner:when is O.dirtySet empty, delete O clean/dirty operations are idempotent Can detect if client terminates without calling clean Attach sequence numbers to each clean/dirty call

7 Study #1: Reference Counting w(O) Object table Surrogate Object for O Process Q Client of O w(O) Object table Concrete Object (O) Process P Owner of O PQ dirty O.dirtySet={ …}O.dirtySet={Q, …} clean

8 Transmitting a Network Object  Marshalling – passing object references between processes (as arguments or as results).  Concrete object never migrates  May pass objects from client-to-client or owner-to-client  Use wireRep to transfer object references: 1.Unique ID of the owner process 2.Index of the object at the owner Next: example when Process P marshals object O to process Q

9 Study #2: Marshalling 1.X sends Q the wireRep with w(O) 2.Q looks up O in its object table: Is there a local surrogate? 3.Case 1: O is not in Q’s object table, or has a weak reference a.Enter w(O) with a NULL reference b.Call dirty to object owner c.Owner adds Q to O’s dirty set, returns dirty call d.Q creates surrogate object, enters it in object table e.Q sends an acknowledgement to X 4.Case 2: w(O) is there but the mapped to a NULL reference  Surrogate creation in under way, wait until created 5.Case 3: Q finds O with a strong reference in its object table  No surrogate is created

10 Study #3: Deleting a Surrogate Responsibility of client’s local garbage collector: 1.Determines surrogate is unreachable from weak references 2.Replaces weak reference with a special NULL value 3.Schedules a clean-up routine Clean-up routine: 3.Re-checks if reference is still NULL. If not, new surrogate was created and no clean-up required. 4.Remove object table entry 5.Queue a wireRep to be processed later by a cleaning daemon Daemon notifies object’s owner – calls clean to owner Owner removes the client from the object’s O.dirtySet

11 Sequence Number Usage  Use seqno(O, P) to detect out-of-order operations.  Retains highest seqno received from each process P that has ever called dirty/clean operations  1 st : Protect against removing P from O’s dirty set because of a late clean call (asynchronous, may arrive at any time)  2 nd : Protect against adding P to O’s dirty set because of a late dirty call (synchronous with surrogate creation)  Drop P’s seqno when P is removed from dirty set

12 Fault Tolerance Communication Failures:  RPC can indicate operation success or failure  When dirty call fails – no surrogate created, add to cleanup  When clean call fails – leave request in daemon’s queue Will be repeated later, or Will execute when owner’s termination is detected Process Termination:  Detect termination using periodic ping’s  If client doesn’t respond after sufficient time, remove it from owner’s dirty set  Can collect objects with surrogates held by dead processes Risk – may mistake communication failure with a dead process

13 Overall Algorithm Evaluation Benefits: Collects unreachable objects and no others (safe and live) Tolerates process/communication failures Leverages from existing process local garbage collector GC is transparent to programmer (runs in parallel) Low overhead (no excess IPC or synchronization) Limitations:  Cannot collect cycles (programmer’s responsibility)  Race between dirty call and surrogate’s clean call during marshalling (workaround: use ACKs from remote processes)  Risks collecting objects in long-lasting communication failures

14 Distributed Garbage Collection for Network Objects  Questions?