Lecture 15 – Dataflow Analysis Eran Yahav 1 yahave/tocs2011/compilers-lec15.pptx.
Damien Doligez Georges Gonthier POPL 1994 Presented by Eran Yahav ([email protected]) Portable,...
-
date post
21-Dec-2015 -
Category
Documents
-
view
219 -
download
0
Transcript of Damien Doligez Georges Gonthier POPL 1994 Presented by Eran Yahav ([email protected]) Portable,...
Damien DoligezGeorges GonthierPOPL 1994
Presented by Eran Yahav ([email protected])
Portable, Unobtrusive Garbage Collection for Multiprocessor Systems
Portable, Unobtrusive Garbage Collection for Multiprocessor Systems
A concurrent, generational garbage collector for a multithreaded implementation of ML - Doligez - Leroy (POPL 1993)
On-the-fly garbage collection: an exercise in cooperation - Dijkstra et al. (1978)
Overview
MotivationConcurrent collection strategiesConcurrent collection constraintsThe basic algorithm (Dijkstra)Doligez-Leroy modelDoligez-Leroy concurrent collector
Concurrent GC
Known as a tough problemPublished algorithms contain simplifying
assumptions that either: impose unbearable overhead on mutators require high degree of hardware/OS support
Other algorithms are buggy
“Stop the world”
all threads synchronically stop and perform GC
introduces sync. between independent threads
T1
T2
T3
T4
Sync. GC Sync. GC
“Stop the world”
all threads synchronically stop and perform GC
introduces sync. between independent threads
T1
T2
T3
T4
Sync. GC
“Stop the world” - Mostly Parallel GC (Bohem et. al)
Uses virtual memory page protections reduces duration of “stop the world”
perioddoes not prevent synchronization between
threads at “stop the world” points
T1
T2
T3
T4
Sync. GCmarking
“Stop the world” - Scalable mark-sweep GC
Uses a parallelization of Bohem’s mostly parallel collector
reduces duration of “stop the world” periods
does not prevent synchronization between threads at “stop the world” points
T1
T2
T3
T4
Sync. GCmarking
“Stop the world” - Real Time GC (Nettles & O’Toole)
Incremental copying collector reduces duration of “stop the world”
periodsdoes not prevent synchronization between
threads at the swap point
T1
T2
T3
T4
Sync. GC
Concurrent collector
run the collector concurrently with user threads
use as little as possible sync between user threads and GC thread
T1
T2
T3
T4
GC
Concurrent Collection strategies
Reference countingcopying (relocation)mark & sweep
Concurrent GC - Reference counting
Locks on reference counters
heap
RC = 2
M1
M2
-1
M3 +1
Concurrent GC - relocation
relocating objects while mutators are running
heap
from toM1
GC
?
M2
?
Concurrent GC - relocation
relocating objects while mutators are running
must ensure that mutators are aware of relocation test on heap pointer deref extra indirection word for each object virtual memory page protections
significant run-time penalty
Concurrent GC - mark/sweep
Mark all threads rootsNo inherent locksMutators may change trace graph during
any collection phase
Heap
Threads
1
Globalvariables
2 3
Multiprocessors facts of life
Registers are local impossible to track down machine registers of
a running process
Synchronization is expensive semaphores and synchronization are only
available through expensive system calls
Unobtrusive?
No overhead on frequent actions: move data between registers and memory deref a heap pointer fill a field in a new heap object
imposes sync. overhead only on reserve actions (for which it is unavoidable)
mutator cooperation with collector is done only at mutator’s convenience
Portable ?
No special use of OS synchronization primitives
no hardware support
Where all else fail
relocating GC algorithms break locality or impose large overhead
proposed incremental algorithms requires global synchronization
mark & sweep - collector working while mutators change trace graph - complicated but possible
The basic algorithm
Dijkstra et al. - “On the fly garbage collection”published in 1978breaks localityassumes fixed set of roots
Heap
Threads
1
Globalvariables
2 3 GC
Dijkstra’s collector
Mark: for each x in Globals do MarkGray(x)
Scan: repeatdirty false for each x in heap do if color[x] = Gray then dirty true MarkGray(x . Sons) color[x] black
until not dirty
Sweep: for each x in heap doif color[x] = white then append x to free listelse if color[x] = black then color[x] white
black gray
white
mark
swee
p
mar
k
upda
te
sweep
allo
cate
Doligez-Leroy model
Damein doligez & Xavier Leroy at 1993a concurrent, generational GC for
multithreaded implementation of MLrelies on ML properties:
compile time distinction between mutable and immutable objects
duplicating immutable objects is semantically transparent
does not stop program threads
Doligez-Leroy model
Do anything to avoid synchronizationtrade collection “quality” for level of
synchronization - allow large amounts of floating garbage
trade collection “simplicity” for level of synchronization - complicated algorithm (not to mention correctness proof)
3
Doligez-Leroy model
Stacks
Minorheaps
Majorheap
Threads
1 2
Globalvariables
Collection generations
Each thread treats the two heaps (private and shared) as two generations private = young generation shared = old generation
immutable objects are allocated in private heaps does not require synchronization
mutable objects handled differently (later)
Minor collection
When private heap is full - stop and perform minor collection
copy live objects from private heap to shared heap (old generation)
after minor collection, whole private heap is free
can be performed in any timesynchronization is only required for allocation
of the copied object on shared heap
Major collection
Dedicated GC threaduses a variation of Dijkstra’s algorithm
(mark & sweep)does not move objects, no synchronization
is required when accessing/modifying objects in shared heap
will be described later
3
Major and minor collection
Stacks
Minorheaps
Majorheap
Threads
1 2
Globalvariables
GC
Copy on update
We assumed no pointers from shared heap to private heap
Majorheap
Not reachablefrom thread’sroots
Copy on update
Copy the referenced object (and descendents)
similar to minor collectionwith a single root
simply does some of theminor collection right away
Majorheap
Copy on update
Until next minor collection, copying thread can access original and copied objects
immutable objects - semantically equivalent
what about mutable objects ?
Majorheap
Allocation of mutable objects
If copied - can update both objects separatelyno equivalence of original and copied objectsolution: always allocate mutable objects in
the shared heaprequires synchronization (free list)ML programs usually use few mutable objectsmutable objects have longer life span than
average
The Concurrent collector
Adapted version of Dijkstra’s algorithmnaming conventions
mutator = thread + minor collection thread collector = major collector
major collector only requires marking of mutator roots.
does not demand minor collections
Four color marking
White - not yet marked (or unreachable)Gray - marked but sons not markedBlack - marked and sons markedBlue - free list blocks
Heap
Collection phases
Root enumerationend of markingsweeping
Root enumeration
Raise a flag to signal beginning of marking shade globalsask mutators to shade rootswait until all mutators answeredmeanwhile - start scanning and marking
Root enumeration
Mark: for each x in Globals do MarkGray(x) call mutator to mark roots wait until all mutators answered...
Cooperate: if call to roots is pending then call MarkGray on all roots answer the call
Collector
Mutators
End of marking
Repeatedly mark gray objects until no more gray objects remain
Scan: repeatdirty false for each x in heap do if color[x] = Gray then dirty true MarkGray (x . Sons) color[x] black
until not dirty
Sweeping
Scan heapAll white objects are free - set to blue and
add to the free listall black objects are reset to whitesome object might have been set to gray
since the end of marking phase - set to white
Invariants (1/2)
All objects reachable from mutator roots at the time mutator shaded its roots, or that become reachable after that time are black at the end of the marking phase
Objects can become reachable by allocation and modificationwhich are performed concurrently with the collection
Invariants (2/2)
gray objects that are unreachable at the beginning of the mark phase become black during mark, then white during sweep and reclaimed by the next cycle (floating garbage)
all white objects unreachable at the start of the marking phase remain white
No unreachable object ever becomes reachable again
there are no blue objects outside the free list
Concurrent allocation and modification
Mutators must consider collector status when performing modification or allocation of heap objects
first, lets consider modification of heap objects
Concurrent modification
Updating a black object could result in a reachable object that remains white at the end of marking
even worse - the set of roots is not fixed during collection
must shade both the new value and the old value
What happens if we don’t shade new value
T1 T2
Majorheap
Mark T1 root
A
B
T2 updates A
Root enumeration
T2 pops
What happens if we don’t shade new value
Majorheap
T1 T2
A
B
Mark T1 root T2 updates A
Root enumeration
T2 pops
What happens if we don’t shade new value
Majorheap
T1 T2
A
B
Mark T1 root T2 updates A
Root enumeration
T2 pops Mark T2 root
End mark Sweep
What happens if we don’t shade old value
T
Majorheap
Mark T root T pushes B
Root enumeration
A
B
End mark
What happens if we don’t shade old value
Majorheap
T
A
B
Mark T root T pushes B
Root enumeration End mark
What happens if we don’t shade old value
Majorheap
T
A
B
Mark T root T pushes B
Root enumeration
T updates A
SweepEnd mark
Concurrent Allocation
Assign right color to new objectsduring marking - allocated objects are
black allocated are reachable sons of allocated are reachable and will
eventually be set to black
sweeping - white if already swept, gray otherwise set to gray to avoid immediate deallocation
Synchronization
It is always safe to set an object to graysetting many objects to gray is inefficient
will be only reclaimed on next cycle
allows us to avoid synchronization when race condition can end up making an object gray
used to test collector status without locking
Synchronization
Coloring of newly allocated block
1. If phase = marking then2. Set object to black3. If phase = sweeping then4. Set object to gray5. Else6. If address(object) < sweep-pointer then7. Set object to white8. Else 9. Set object to gray
SM
SSS
SSSSS
Color transitions summary
black gray
blue white
mark
allocate sweep
sweep
mark
allocate
update
sweep
allocat
e
Experimental results
Corrections
When shading old value - what old value do we shade ?
Another thread might “replace” old value, after we shade it, by a non-shaded value
this is corrected by adding another handshake - all updates must end before we start marking
Summary
Doligez Leroy & Gonthier concurrent GCdoes not stop program threadsfour colors mark & sweep - white,gray,
black and bluerelies on ML language properties, but can
be extended for other languages
The End