1. Damien Doligez Georges Gonthier POPL 1994 Presented by Eran Yahav (yahave@math.tau.ac.il) Portable, Unobtrusive Garbage Collection for Multiprocessor Systems

2. 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)

3. Overview Motivation Concurrent collection strategies Concurrent collection constraints The basic algorithm (Dijkstra) Doligez-Leroy model Doligez-Leroy concurrent collector

4. Concurrent GC Known as a tough problem Published algorithms contain simplifying assumptions that either:  impose unbearable overhead on mutators  require high degree of hardware/OS support Other algorithms are buggy

5. “Stop the world” all threads synchronically stop and perform GC introduces sync. between independent threads T1T1 T2T2 T3T3 T4T4 Sync. GC

6. “Stop the world” all threads synchronically stop and perform GC introduces sync. between independent threads T1T1 T2T2 T3T3 T4T4 Sync. GC

7. “Stop the world” - Mostly Parallel GC (Bohem et. al) Uses virtual memory page protections reduces duration of “stop the world” period does not prevent synchronization between threads at “stop the world” points T1T1 T2T2 T3T3 T4T4 Sync. GCmarking

8. “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 T1T1 T2T2 T3T3 T4T4 Sync. GCmarking

9. “Stop the world” - Real Time GC (Nettles & O’Toole) Incremental copying collector reduces duration of “stop the world” periods does not prevent synchronization between threads at the swap point T1T1 T2T2 T3T3 T4T4 Sync. GC

10. Concurrent collector run the collector concurrently with user threads use as little as possible sync between user threads and GC thread T1T1 T2T2 T3T3 T4T4 GC

11. Concurrent Collection strategies Reference counting copying (relocation) mark & sweep

12. Concurrent GC - Reference counting Locks on reference counters heap RC = 2 M1M1 M2M2 M3M3 +1

13. Concurrent GC - relocation relocating objects while mutators are running heap fromto M1M1 GC ? M2M2 ?

14. 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

15. Concurrent GC - mark/sweep Mark all threads roots No inherent locks Mutators may change trace graph during any collection phase Heap Threads 1 Global variables 23

16. 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

17. 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

18. Portable ? No special use of OS synchronization primitives no hardware support

19. 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

20. The basic algorithm Dijkstra et al. - “On the fly garbage collection” published in 1978 breaks locality assumes fixed set of roots Heap Threads 1 Global variables 23GC

21. Dijkstra’s collector Mark: for each x in Globals do MarkGray(x) Scan: repeat dirty  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 do if color[x] = white then append x to free list else if color[x] = black then color[x]  white black gray white mark sweep mark update sweep allocate

22. Doligez-Leroy model Damein doligez & Xavier Leroy at 1993 a concurrent, generational GC for multithreaded implementation of ML relies on ML properties:  compile time distinction between mutable and immutable objects  duplicating immutable objects is semantically transparent does not stop program threads

23. Doligez-Leroy model Do anything to avoid synchronization trade 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)

24. 3 Doligez-Leroy model Stacks Minor heaps Major heap Threads 12 Global variables

25. 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)

26. 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 time synchronization is only required for allocation of the copied object on shared heap

27. Major collection Dedicated GC thread uses 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

28. 3 Major and minor collection Stacks Minor heaps Major heap Threads 12 Global variables GC

29. Copy on update We assumed no pointers from shared heap to private heap Major heap Not reachable from thread’s roots

30. Copy on update Copy the referenced object (and descendents) similar to minor collection with a single root simply does some of the minor collection right away Major heap

31. Copy on update Until next minor collection, copying thread can access original and copied objects immutable objects - semantically equivalent what about mutable objects ? Major heap

32. Allocation of mutable objects If copied - can update both objects separately no equivalence of original and copied object solution: always allocate mutable objects in the shared heap requires synchronization (free list) ML programs usually use few mutable objects mutable objects have longer life span than average

33. The Concurrent collector Adapted version of Dijkstra’s algorithm naming conventions  mutator = thread + minor collection thread  collector = major collector major collector only requires marking of mutator roots. does not demand minor collections

34. Four color marking White - not yet marked (or unreachable) Gray - marked but sons not marked Black - marked and sons marked Blue - free list blocks Heap

35. Collection phases Root enumeration end of marking sweeping

36. Root enumeration Raise a flag to signal beginning of marking shade globals ask mutators to shade roots wait until all mutators answered meanwhile - start scanning and marking

37. 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

38. End of marking Repeatedly mark gray objects until no more gray objects remain Scan: repeat dirty  false for each x in heap do if color[x] = Gray then dirty  true MarkGray (x. Sons) color[x]  black until not dirty

39. Sweeping Scan heap All white objects are free - set to blue and add to the free list all black objects are reset to white some object might have been set to gray since the end of marking phase - set to white

40. 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 modification which are performed concurrently with the collection

41. 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

42. Concurrent allocation and modification Mutators must consider collector status when performing modification or allocation of heap objects first, lets consider modification of heap objects

43. 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

44. What happens if we don’t shade new value T1T2 Major heap Mark T1 root A B T2 updates A Root enumeration T2 pops

45. What happens if we don’t shade new value Major heap T1T2 A B Mark T1 rootT2 updates A Root enumeration T2 pops

46. What happens if we don’t shade new value Major heap T1T2 A B Mark T1 rootT2 updates A Root enumeration T2 popsMark T2 root End markSweep

47. What happens if we don’t shade old value T Major heap Mark T rootT pushes B Root enumeration A B End mark

48. What happens if we don’t shade old value Major heap T A B Mark T rootT pushes B Root enumerationEnd mark

49. What happens if we don’t shade old value Major heap T A B Mark T rootT pushes B Root enumeration T updates A SweepEnd mark

50. Concurrent Allocation Assign right color to new objects during 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

51. Synchronization It is always safe to set an object to gray setting 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

52. Synchronization Coloring of newly allocated block 1. If phase = marking then 2. Set object to black 3. If phase = sweeping then 4. Set object to gray 5. Else 6. If address(object) < sweep-pointer then 7. Set object to white 8. Else 9. Set object to gray S M S S S S S S S S

53. Color transitions summary blackgray bluewhite mark allocate sweep mark allocate update sweep allocate

54. Experimental results

55. 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

56. Summary Doligez Leroy & Gonthier concurrent GC does not stop program threads four colors mark & sweep - white,gray, black and blue relies on ML language properties, but can be extended for other languages

57. The End