© richard jones, 2000directions for distributed garbage collection microsoft research, 7 august...
TRANSCRIPT
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
1
Directions for Distributed Garbage Collection
Directions for Distributed Garbage Collection
Richard JonesComputing Laboratory
University of Kent at Canterbury
Richard JonesComputing Laboratory
University of Kent at Canterbury
Microsoft Research, CambridgeMonday 7 August 2000
©Richard Jones, 2000. All rights reserved.
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
2
OutlineOutline
Motivation
Model
An ideal GC
Why conventional taxonomies are unsatisfactory
A new taxonomy
What this taxonomy offers
Examples
DGC in practice
Research directions
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
3
Motivation: GCMotivation: GC
Why GC?• “Illusion of infinite memory” ??• A safety net?• Language requirement• Problem requirement (ownership)
Software engineering• Liveness is a global question• Modularity• Abstraction
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
4
Motivation: DGCMotivation: DGC
Arguments above apply
• Liveness is now an even harder problem
Open systems
• Location transparency
• Lack of control over components
Fault tolerance
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
5
Motivation: this talkMotivation: this talk
Several previous attempts at DGC survey• [abdu92,abdu98]
– Quite full, little structure or rationale, ?accuracy
• [plai95]– Better structure but incomplete
• Lins in [jone96]– Short on detail
Towards a well-structured, complete survey
Avoid centralised GC legacy
Insight into new areas for researchReferences: http://www.cs.ukc.ac.uk/people/staff/rej/gcbib.html
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
6
Model and terminologyModel and terminology
Processes exchange messages
Failure model is fail-stop: no Byzantine failures
Mutators, local collectors, distributed collectors
Liveness by reachability
Entry and exit items
Local and global roots
• Local: roots for the process
• Global: entry items which may be reachable from a local
root of another process
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
7
Root setRoot set
Local roots
Global roots
Local roots
Remotelyreachable
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
8
Properties of an ideal DGCProperties of an ideal DGC
safety:• only garbage should be reclaimed.
completeness:• all objects, including components
of distributed cycles, that are garbage at the start of a collection cycle should be reclaimed by its end.
concurrency:• neither mutator nor local collector
processes should be suspended; distinct distributed collection processes should run concurrently.
promptness:• garbage should be reclaimed
promptly.
efficiency:• time and space costs should be
minimised.locality:
• inter-process communication should be minimised.
expediency:• garbage should be reclaimed
despite the unavailability of parts of the system.
scalability:• the collector should scale to
networks of many processes.fault tolerance:
• it should be robust against message delay, loss or replication, or process failure.
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
9
Strategy/policy/mechanismStrategy/policy/mechanism
Wilson suggests classification by strategy,
policy and mechanism [wils95].
Malloc example:
• Strategy: “don’t let small objects prevent
reclamation of a larger contiguous area”
• Policy: best-fit
Most taxonomies are based on mechanisms
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
10
Conventional mechanisms• Reference counting• Mark-sweep• Mark-compact• Copying
Generations
LOA
Single
Region organisation• Single• Large object area• Generational
Generations
LOASingle
Concurrent
Incremental
Sequential
Parallelism
Conventional taxonomyConventional taxonomy
RC MS MC Copy
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
11
ConsequencesConsequences
(almost) All direct mechanisms are variants of simple reference counting.
All indirect mechanisms are tracing collectors
Conventional conclusion:
indirect tracing
RC cannot reclaim garbage cycles.
Conventional conclusion:
All complete algorithms are indirect
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
12
What’s the problem?What’s the problem?
Indirect collectors are better called “live object detectors”
They are set-difference algorithms: they must provide an estimate of the set of live objects.
Depending on conservatism of this estimate• Not scalable — every site must participate, or
• Not complete — assume live if no other information
Synchronisation of phases is a bottleneck
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
13
Direct algorithmsDirect algorithms
Direct algorithms are inherently scalable.• E.g. simple RC requires cooperation of
only 3 objects• Only necessary to visit objects that might
be garbage
It is always safe for a direct algorithm to ‘give up’ early in discovering garbage
• At worst this defers reclamation (e.g. [weiz69])
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
14
Barrier technologyBarrier technology
Appropriateness of barrier technology changes as we move from centralised to distributed systems.
Read barriers are conventionally held to be expensive (as reads are much more common than writes).
But this overhead is diminished in context of message passing. Combinations of read and write barriers become viable.
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
15
Tricolour abstractionTricolour abstraction
Black• object and its immediate descendants have been visited• GC has finished with black objects and need not visit again.
Grey • object has been visited but its components may not have been
scanned. • or, for an incremental/concurrent GC, the mutator has rearranged
connectivity of the graph. • in either case, the collector must visit them again.
White • object is unvisited and, at the end of the phase, garbage.
A collection terminates when no grey objects remain, i.e. all live objects have been blackened.
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
16
Barrier technologyBarrier technology
There are two ways to prevent the mutator from interfering with a collection by writing white pointers into black objects.
1) Ensure the mutator never sees a white object• when mutator attempts to access a white object,
the object is visited by the collector• protect white objects with a read-barrier
2) Record where mutator writes black-white pointers• GC can (re)visit modified objects• protect objects with a write-barrier
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
17
Additional goalsAdditional goals
Necessity for compromises• scalability, fault-tolerance and efficiency may only
be achievable at the expense of completeness,
• concurrency introduces synchronisation overheads.
Lack of empirical data
A further goal:• Flexibility — the collector should be configurable,
guided by heuristics or hints
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
18
A more appropriate taxonomyA more appropriate taxonomy
A simple, orthogonal taxonomy but captures all proposed DGC algorithms
Indirect• Non-tracing• Tracing
Direct• Non-tracing• Tracing
Note also Louboutin’s Proactive/Reactive taxonomy [loub98] — more later
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
19
Indirect, non-tracing DCIndirect, non-tracing DC
Global-root graph reconstruction• Liskov & Ladin algorithms [lisk86, ladi92]
• (replicated) Central service + Clients
• Client local GC passes Service lists
– Acc: all non-resident objects reachable from local roots
– Paths: all pairs (g1,g2) where g2 is a remote global root
reachable from locally unreachable global root g1
– Trans: references in transit
• Service reconstructs graph of global roots
• Periodically Clients query Service asking which of its global
roots are no longer globally reachable
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
20
Leases• Provide fault tolerance by preventing leaks in the face of
remote process failure
• Clients take out a lease on a remote object
• Until this lease expires, object is protected from local collector
• Java RMI:– Lease default is 10 minutes
– Leases renewed every 5 minutes
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
21
Indirect, tracing DGCIndirect, tracing DGC
Classify by the degree of synchronisation required.
Centralised: single initiating process• Examples: [huda82, augu87, juul92]
Partitioned: a partition of processes cooperates to collect independently of other processes
• Example: [lang92a]
Autonomous: multiple, simultaneous collections • Timestamp propagation: pipelined collections• Examples: [hugh85, fess98]
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
22
AugusteijnAugusteijnProcess initiates collection (active-disquiet)
• Sends scan request to remote processes for which it holds references
On receipt of a scan request, a process
• disquiet: adds request to its work queue, ACKs immediately
• quiet: processes request (disquiet), ACKs on completion
Stable algorithm.• Only disquiet processes can send
requests. • Always chain of responsibility from
each disquiet process back to active process.
Marking terminates when initiator has received ACK of each scan request sent
ActiveDisquiet
PassiveQuiet
PassiveDisquiet
receivedall ACKs
receivedmark request
receivedall ACKs
receivedmark request
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
23
Garbage collecting the worldGarbage collecting the world
1. Processes negotiate partitions
2. Processes send decrement messages from each exit-item• At end, entry-items with positive counters (hard) are
reachable from outside the group; other entry-items are soft.
3. Global mark within the group from 1. local roots and black entry-items propagating black
2. Soft entry-items marking unvisited items soft
4. Detect termination and reclaim soft entry-items
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
24
Timestamp algorithmsTimestamp algorithms
All global objects contain time-stamps.
Time-stamp of new object is local time.
Local GC propagates time stamps to remote objects• Time-stamp of remote object is increased if lower than value
in message
Intuition: time-stamp of garbage never increases
Process p has time-stamp redop time-stamp of any live object in this process
minredo = min {redop | pprocesses}
Any object with time-stamp redo is garbage.
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
25
Direct, non-tracing DGCDirect, non-tracing DGC
Reference Counting• Standard RC algorithm insufficient — race conditions• Simple protocol to avoid premature reclamation [lerm86]• Weighted RC avoids race: doesn’t send INC messages
[beva87,wats87]• Diffusion tree algorithms [piqu91, more98a]
Reference Listing • Maintain lists of processes holding reference to global root
rather than a count• More fault tolerant• Examples: Network Objects [birr93], SSP chains [shap92a]
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
26
Copying• ‘Move’ locally unreachable global objects to site that
references them — require an ordering on sites• ‘Move’ may be real or virtual [bish77,vest87,shap90,huds97]
Causal dependency tracking• Analyse mutator’s computation graph directly
[sche89,loub98]
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
27
Direct, tracing GCDirect, tracing GC
Completeness requires tracing.
Direct algorithms offer scalability.
How can we combine these ideas to produce effective DGCs?
Back-tracing• Examples: [fuch95, mahe97]
Partial tracing• Example: [rodr98]
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
28
Back-tracingBack-tracing
Identify suspects
Back-step(o) for some exit-item o
Back-step(e)• If e is not a suspect, return Live
• If e is marked, return Garbage
• Mark e
• For each remote object r pointing to e
if Back-step(r) is Live, return Live
• Return Garbage
Problem of multiple overlapping traces
RX
X
X
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
29
Partial tracingPartial tracing
Identify suspects1. Mark red from these suspects
• Construct ‘red sets’ (akin to ‘client sets’)• Dynamically forms a group
2. Scan suspects whose red and client sets differ• Rescues objects inadvertently marked red — mark them
green• Run all scans concurrently
3. Reclaim any red objects
Group merger scheme permits multiple, overlapping collections
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
30
Mark-redMark-red
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
31
ScanScan
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
32
BenefitsBenefits
Both schemes • Are direct — attempt to trace only garbage• Are scalable — can limit extent of trace (by process, by
object, by hop-count,…)• No global synchronisation• Can take advantage of heuristics
Partial tracing• Mark-red does not have to synchronise with mutators• Scan synchronisation through read and write barriers,
DGC piggy-backs on mutator messages for fault tolerance• [rodr98] shows how to manage overlapping traces
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
33
What this taxonomy offersWhat this taxonomy offers
Simple and orthogonal approach
Offers complete taxonomy
Not distracted by legacy of centralised GC
Identifies new, scalable approaches
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
34
Louboutin taxonomyLouboutin taxonomy
Global garbage detection• Proactive
– In-situ graph colouring– Global-root graph reconstruction
• Reactive– Time-stamp packet distribution– IRC– WRC– RL
comprehensive
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
35
In practiceIn practice
Many direct, acyclic schemes
Tracing is only needed to recover cycles
How do these arise in practice?• Stereotypes
– A holds reference to B, and B holds reference to A
– E.g. Callbacks
– Use a Design Pattern to manage these by explicitly dropping references e.g. Client sends Disconnect; Server drops callback
• General patterns– Do these arise?
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
36
Further researchFurther research
Object demographics• Study real applications• How do distributed objects behave? How much of this
behaviour is imposed by limits of DGC technology?
Frameworks for DGC• Build a framework into which component DGCs could be
pluggedcf. Sun’s RVM for Java
Comparative analysis• How do different DGCs perform against different
applications?• Allow developers to pick
© Richard Jones, 2000 Directions for Distributed Garbage CollectionMicrosoft Research, 7 August 2000
37