1. Copyright, 1996 © Dale Carnegie & Associates, Inc. Mark-Sweep A tracing garbage collection technique Hagen Böhm November 21st, 2001 hagen@net.uni-sb.de

2. The basic mark-sweep algorithm n first algorithm for automatic storage reclamation (McCarthy 1960) n a stop and run algorithm n tracing garbage collection technique

3. The basic mark-sweep algorithm n works in 2 Phases: u mark all live nodes by global traversal u sweep the heap by a linear scan

4. The basic mark-sweep algorithm n benefits u handles cycles naturally u no overhead on pointer manipulations u low space cost: using a simple mark-bit (architecture depend!!!)

5. The basic mark-sweep algorithm n drawbacks u computation halted while gc u high costs! F every active cell is visited by marking F all cells are examined by sweep F recursive marking (time and space!) u tending to fragment memory => programs may “thrash” u heap residency too large => gc will become high frequently

6. Outlook onto improvements n iterative solution to marking using a marking stack u minimising the depth of the stack u handling overflows n pointer reversal n bitmap marking n lazy sweeping

7. Iterative marking n Recursive procedure calls are time- and space- wasting u reserving/discarding working space u procedure call overheads n improve the performance by... u replacing recursive calls by iterative loops u using an auxiliary stack for pointers to nodes known to be live.

8. Iterative marking

17. Minimising stack depth n pushing constituent pointers of large objects in small groups onto the stack n using pointer reversal (more later)

18. Handling Stack Overflow n Knuth proposal in 1973 u treating the marking stack circularly u scan_heap returns marked nodes pointing to unmarked nodes

19. Handling Stack Overflow n Kurokawa proposal in 1981 u remove items from stack that have fewer than 2 unmarked children F no child is unmarked: clear slot F one child is unmarked: replace slot entry by a descendent with 2 or more unmarked children marking the passed ones u approach is not robust!!!

20. Pointer reversal n efficient marking must record the trace it passed n temporarily reversing of pointers traversed by mark (child-pointers become ancestor-pointers) n restore pointer fields when tracing back n developed independently by Schorr and Waite (1967) and by Deutsch (1973)

21. Pointer reversal advanceretreat switch enter unmarked atom or marked internal node of sub-graph head of graph head of sub-graph DFA for binary tree structures

22. Pointer reversal (advance phase) previous current

23. Pointer reversal (advance phase) previous current

24. Pointer reversal (advance phase) previous current next

25. Pointer reversal (advance phase) previous current next

26. Pointer reversal (advance phase) previous current next

27. Pointer reversal (advance phase) previous current next

28. Pointer reversal (switch phase) previous current next

29. Pointer reversal (switch phase) previous current next

30. Pointer reversal (switch phase) previous current next

31. Pointer reversal (switch phase) previous current next

32. Pointer reversal (switch phase) previous current next

33. Pointer reversal (switch phase) previous current next

34. Pointer reversal (retreat phase) previous current next

35. Pointer reversal (retreat phase) previous current next

36. Pointer reversal (retreat phase) previous current next

37. Pointer reversal (retreat phase) previous current next

38. Pointer reversal (retreat phase) previous current next

39. Pointer reversal for variable- sized nodes n 2 additional fields per node u n-field: total number of pointer fields u i-field:number of sub-trees fully marked n i > 0: node is marked n i == n: all children have been marked

40. Features of pointer reversal requires constant space (only 3 pointers: current, previous, next) n hides the marking stack in heap nodes (overhead is shifted!!) n requires high time-cost: u visits each branch-node at least (n+1) times u each visit requires additional memory fetches u each visit cycles 4 values + reading/writing mark-flags

41. Pointer reversal conclusion Don’t use pointer reversal!!!! except for having problems with stack overflow...

42. Bitmap marking n Problem: where to find space for mark- bits in objects? n Solution: store them in a separate bitmap table

43. Features of bitmap marking n one bit start-address of object in heap n size of bitmap inversely proportional to size of smallest object n the bit corresponding to an object is accessed by shifting object’s address

44. Bitmap marking (example) n 32-bit architecture n smallest object = 2 words bitmap takes about 1.5 % of heap. if p is start address of object, then mark-bit is accessed by: mark_bit(p) = return bitmap[p>>3];

45. Bitmap marking pro/contra n benefits u requires small space u bitmap mostly can held in RAM u heap mustn’t be contiguous u mark-bits can be saved due to large objects u big atomic objects never be touched u in sweep no object need to be accessed n drawbacks u access bitmap more expensive than writing to object

46. Lazy sweeping n Problem : sweep phase expensive!!! n But: u pre-fetching pages or cache lines will be profitable u much less likely to effect virtual memory behaviour

47. Lazy sweeping n Problem: sweep interrupts user program!!! n Improvement: execute sweep in parallel with mutator

48. Hughes’s lazy sweeping [1982] n do a fixed amount of sweeping at each allocation n sweep-phase cost transferred to allocation n no free-list manipulations n bitmaps reduce performance!!!

49. Boehm-Demers-Weiser sweeper [first in 1988] n 2-level allocation: u low-level: acquire blocks from OS for single sized objects u high-level: assign objects to the blocks n free-list for each object size, threaded through blocks n queues for reclaimable blocks

50. Block header n one header per block held on linked- list containing additional info hb_sz hb_next hb_descr hb_map hb_obj_kind hb_flags hb_last_reclaimed hb_marks Size of objects in block block header to be reclaimed (atomic, normal) mark bits

51. Zorn’s lazy sweeper [1989] n for each object size => cache vector of n objects n Vector empty? Sweep to refill it! n sweeping = allocating (10-12 cycles)

52. MS? RC? CC? n Tracing gc = much lower overhead on mutator than RC n considering caching/virtual memory environment, answer gets more difficult (MS or CC???) n depends on application!

53. Space and locality mark-sweep... u require less address space u has better cache and vm behavior u bitmap improvement (only reading live, non-atomic objects in mark-phase) u adding object to free-list may cause page fault/cache miss

54. Time complexity L = volume live data in heap R = residency user program M = heap size Amortized cost are the same, constants not! Object size is important! Copying collector better to implement :-(