Review. Partitioning: Divide heap, use different strategies per heap Generational GC: Partition by age Most objects die young

Transcription

1 Generational GC 1

2 Review Partitioning: Divide heap, use different strategies per heap Generational GC: Partition by age Most objects die young 2

3 Single-partition scanning Stack Heap Partition #1 Partition #2 3

4 Single-partition scanning Stack Heap Partition #1 Partition #2 Don t follow pointers out of partition: Not our job 3

5 Single-partition scanning Stack Heap Partition #1 Partition #2 Don t follow pointers out of partition: Not our job Our partition s objects could be referenced by other partitions 3

6 Single-partition scanning Stack Heap Partition #1 Partition #2 4

7 Single-partition scanning Stack Heap Partition #1 Partition #2 Cannot be collected! 4

8 Alternate approach Stack Heap Partition #1 Partition #2 Pseudoroot 5

9 The big idea Most objects die young Partition heap by age Nursery partition collected frequently Old partition only collected during fullheap GC 6

10 Inter-partition references Never collect old partition without young Only need to remember old young interpartition references Write barrier is back! (Details later) Treat old objects w/ young refs as roots 7

11 Generational GC Stack Nursery Heap Old generation 8

12 Generational GC Stack Nursery Heap Old generation No need to specially mark this reference 8

13 Generational GC Stack Nursery Heap Old generation No need to specially mark this reference Need to remember this reference when doing young GC 8

14 Promotion Stack Nursery Heap Old generation 9

15 Promotion Stack Nursery Heap Old generation 9

16 Promotion Stack Nursery Heap Old generation 9

17 En masse generational When nursery is full, collect nursery Copying GC, treat old generation as tospace Old gen can have any allocator After GC, nursery is empty by definition When old generation is full, full collect 10

18 When to GC Allocation in old generation only done by young GC GC of old generation only done due to allocation in old generation Therefore: Full collection caused by partial young collection 11

19 Weird promotions Old generation is full, GC everything Cannot now promote: Old gen is full! Nursery in half-collected state, but can t continue copying 12

20 Solution: No worries! Update references to already-copied objects Scan but don t copy newly-found young objects When finished with full collection, collect young again Careful for collection loops! 13

21 En-masse advantages Copying without semispaces: No wasted heap Young collection very fast Young-death objects don t impact performance 14

22 GC timeline Time O1 O2 alloc alloc O3 alloc O1 dies O4 alloc GC O2 dies O5 alloc O3 dies O6 alloc 15

23 GC timeline Time O1 O2 alloc alloc O3 alloc O1 dies O4 alloc GC O2 dies O5 alloc O3 dies O6 alloc Wrongly promoted, will take a long time to collect! 15

24 Tempered generational GC Don t promote objects on first GC Decide whether to promote from age Leave very young objects in nursery 16

25 Determining age Wall clock: Easy: Put time in header, check it Problem: Machine- and program-dependent, young for one app may be old for other Memory age (words allocated since): Robust to app differences Difficult/impossible to implement 17

26 Determining age Collection count: Every time object survives collection, collection count +1 Approximates memory age Easy to track: Add counter to header 18

27 Collection counter Stack Nursery tospace 0 0 fromspace 1 Heap Old generation 19

28 Collection counter Stack Nursery fromspace Heap Old generation tospace

29 Collection counter Stack Nursery tospace 2 2 Heap Old generation fromspace 21

30 Collection counter Stack Nursery tospace 2 2 Heap Old generation fromspace Created inter-generational link during GC! 21

31 Collection counter Stack Nursery tospace 2 2 Heap Old generation With young gen copying, still need semispace: Wasted heap fromspace Created inter-generational link during GC! 21

32 Collection counter Semispace problems are back: Waste half of young space Not all objects promoted: Can create intergenerational links 22

33 The bucket brigade Alloc GC GC 0 1 Old Nursery Old generation 23

34 The broken bucket brigade Alloc GC GC fromspace tospace 0 Nursery Old generation 24

35 Bucket brigade Copy objects from bucket n to bucket n+1 Cannot just use semispace copying with from=0, to=1: tospace already partially used Emptied tospace prefix not available 25

36 The Java bucket brigade Alloc GC GC fromspace 0 Old tospace Nursery Old generation 26

37 Java [HotSpot] collection Nursery: Bucket 0 ( Eden ) flat space Bucket 1 ( Survivor ) semi-space copying Old generation mark-and-compact 27

38 Young collection algorithm youngcollect(): (scan roots) b1fromspace, b1tospace := b1tospace, b1fromspace while loc := worklist.pop(): obj := *loc if!obj->header.forward: if obj in bucket 0: obj->header.forward := (copy to b1tospace) else if obj in bucket 1: obj->header.forward := (copy obj to old gen) (add references in newly-copied object) *loc := obj->header.forward 28

39 Overhead But still wasting heap for semispaces! Most objects die young: Even by bucket 1, most objects dead Remember: You allocate pools, so you choose heap, generation, bucket sizes! Typically, bucket 0 32x larger than one space in bucket 1 29

40 Caveat Of course, bucket 0 could fill b1tospace Expand b1 spaces during collection: Want H=n*L (all objects copied in are in L) Can t expand more? Fallback to copying to old gen 30

41 Breather Alloc GC GC fromspace 0 Old tospace Nursery Old generation 31

42 Write barrier To collect just nursery, remember objects in old generation which have inter-generation references In practice: Over-approximate Treat portions of old generation as roots for nursery collection 32

43 Remembered set Remember a portion of old generation as interesting During young GC, scan objects in remembered set During full GC, clear remembered set 33

44 Cards Typical (read: Java) GCs use cards Divide pools into smaller chunks called cards of power-of-2 size Remembered set is bit-array of size #-ofcards-per-pool To remember a card, mark its bit 34

45 Card barrier write(obj, loc, val): if genof(obj) == old and genof(val) == young: poolof(obj)->remember[cardof(obj)] := 1 *loc = val poolof(ptr): ptr & POOL_MASK cardof(ptr): (ptr & ~POOL_MASK) >> CARD_SIZE_POW2 35

46 Card use During young GC, scan each old pool s remembered set For each 1, scan objects in corresponding card Note: Cards must be parsable! 36

47 Parsable cards Objects may span cards To parse card, need to know offset of first object in card Additional element in pool: Offsets of first objects within cards 37

48 Parsable cards oldallocate(): bump-pointer : ret := end end += size if cardof(obj)!= cardof(end): pool->firstobjs[cardof(end)] := offsetincard(end) split free-list : if cardof(ret)!= cardof(split): pool->firstobjs[cardof(split)] := offsetincard(split) 38

49 Summary Young gen in buckets, promoted to old gen from oldest bucket Oldest bucket semispace Pointers from old gen remembered by cards Cards treated like roots (but scanned as objects) 39

50 Cards (part deux) 40

51 Cards Partitioned (e.g. generational) GC must remember certain inter-partition refs Remembering each object too expensive Divide generation into cards 41

52 Pools with cards struct Pool { struct Pool *next; struct FreeObject *freeobjects; void *freespace; char remember[cards_per_pool]; unsigned short firstobjs [CARDS_PER_POOL]; }; 42

53 Allocation with cards Remember: firstobjs there to make cards parsable Need to worry about firstobjs Matters during: Bump-pointer allocation Free-list allocation splitting Coalescence 43

54 Parsing cards scancard(pool, cardno): loc := pool + cardno*card_size + pool->firstobj[cardno] while cardof(loc) == cardno: obj := loc (scan this object) loc += obj->header.size 44

55 youngcollect(): (add roots to worklist) (add remembered set to worklist) fromspace, tospace := tospace, fromspace while loc := worklist.pop() obj := *loc if obj is young and!obj->header.forward: if obj->header.collectioncount < 1: (move obj to newobj in tospace) obj->header.collectioncount++ obj->header.forward = newobj else: newobj := (try old gen allocator) if newobj == NULL: collectfull() (retry young collection) obj->header.forward = newobj (scan newobj) if obj->header.forward: *loc := obj->header.forward 45

56 youngcollect(): (add roots to worklist) Using e.g. scancard (add remembered set to worklist) fromspace, tospace := tospace, fromspace while loc := worklist.pop() obj := *loc if obj is young and!obj->header.forward: if obj->header.collectioncount < 1: (move obj to newobj in tospace) obj->header.collectioncount++ obj->header.forward = newobj else: newobj := (try old gen allocator) if newobj == NULL: collectfull() (retry young collection) obj->header.forward = newobj (scan newobj) if obj->header.forward: *loc := obj->header.forward 45

57 youngcollect(): (add roots to worklist) Using e.g. scancard (add remembered set to worklist) fromspace, tospace := tospace, fromspace while loc := worklist.pop() Ignore old objects obj := *loc if obj is young and!obj->header.forward: if obj->header.collectioncount < 1: (move obj to newobj in tospace) obj->header.collectioncount++ obj->header.forward = newobj else: newobj := (try old gen allocator) if newobj == NULL: collectfull() (retry young collection) obj->header.forward = newobj (scan newobj) if obj->header.forward: *loc := obj->header.forward 45

58 youngcollect(): (add roots to worklist) (add remembered set to worklist) fromspace, tospace := tospace, fromspace while loc := worklist.pop() obj := *loc if obj is young and!obj->header.forward: if obj->header.collectioncount < 1: (move obj to newobj in tospace) obj->header.collectioncount++ obj->header.forward = newobj else: newobj := (try old gen allocator) if newobj == NULL: collectfull() (retry young collection) obj->header.forward = newobj (scan newobj) if obj->header.forward: *loc := obj->header.forward Using e.g. scancard Ignore old objects Remember: This could have created inter-partition references! 45

59 Runtime interface 46

60 Review Unreachable objects dead Sweep, copying, compacting, ref counting Combine with partitioning, generational Most objects die young, so partitioning by age universal Also useful to partition large objects, threads, executable objects, etc 47

61 Runtime interface Compiler, memory manager and (possibly) programmer must agree Compiler motivated by language, so memory manager often motivated by language too GGGGC s interface is simple by design 48

62 Runtime interface Important components: Allocation Where references are in roots, objects When collection can occur Barriers on writing to (reading from?) objects 49

63 Allocation 50

64 Allocation C malloc Just give me some bytes. Memory manager needs no type info. Object returned full of garbage. 50

65 Allocation C malloc Just give me some bytes. Memory manager needs no type info. Haskell allocation I promise not to touch! Memory manager knows all! Object returned full of garbage. Object returned fully initialized, immutable. 50

66 Allocation C malloc Just give me some bytes. Memory manager needs no type info. Java new Good enough is good enough. Memory manager needs refs. Haskell allocation I promise not to touch! Memory manager knows all! Object returned full of garbage. Object returned full of zeroes. Object returned fully initialized, immutable. 50

67 Allocation and initialization Time Allocation Initialization Use 51

68 Allocation and initialization Time C Allocation Initialization Use Manager Mutator Java Haskell Manager Manager Mutator Mutator 51

69 Constructor problem GC depends on correct objects Correct for us means: References refer to valid objects or NULL If an object scanned mid-initialization, it may not be correct! Options: Prevent GC mid-initialization, or initialize ourselves 52

70 Mid-initialization GC If initialization cannot allocate objects, we could prevent collection Does not generalize Initialization often not guaranteed correct anyway (just user code) Generally, manager must initialize 53

71 Zeroing Simple initialization: All bits zero Mundane value for virtually all types Simple initialization for manager Consequence: Objects initialized twice! (Once by manager, once by program) 54

72 When to zero 55

73 When to zero During allocation Makes allocation slower. Inefficient to spread work over many allocations. 55

74 When to zero During allocation Makes allocation slower. Inefficient to spread work over many allocations. During collection Makes collection (much!) slower. Impossible with freelist. Efficient. 55

75 When to zero During allocation Ahead of allocation During collection Makes allocation slower. Inefficient to spread work over many allocations. Zero chunks beyond current object during allocation. Choose chunk size wisely (cache line or page) for efficiency. Makes collection (much!) slower. Impossible with freelist. Efficient. 55

76 Runtime interface Important components: Allocation Where references are in roots, objects When collection can occur Barriers on writing to (reading from?) objects 56

77 How to identify references 57

78 How to identify references Conservative If it looks like it might be a reference, it s a reference. 57

79 How to identify references Conservative If it looks like it might be a reference, it s a reference. Precise Compiler must know location of all references and tell the GC. Usual for staticallytyped languages. 57

80 How to identify references Conservative If it looks like it might be a reference, it s a reference. Tagged References stored differently from data. Known only at runtime. Precise Compiler must know location of all references and tell the GC. Usual for dynamically-typed languages. Usual for staticallytyped languages. 57

81 Tagged references function FancyString(x) { return "\"" + x.tostring() + "\""; } This code works whether x is a reference or not (That s JavaScript!) 58

82 Refresher: Bit-sneakiness There are three 1 wasted bits in our header Pool address Object address Always 0! All pointers have this extra space! 1 On 32-bit systems, two 59

83 Tagged references Use extra bits as type e.g.: References end in 000, Integers end in 1, Strings end in 010, Compiler and GC must agree Compiler must untag values to use them 60

84 Tagged references trace(obj): for loc in obj to obj + (size) if (*loc & 0b111) == 0: trace(*loc) 61

85 Precise object references You ve seen plenty of this! Bitmaps is pretty much how it s done In some (usually functional) language, object type includes trace function: Compiler creates trace function per type GC calls trace function referred to in descriptor 62

86 Stack references Pointer stacks (ala GGGGC) is not the most common choice Options: Secondary reference stack Parsable stack Heap-allocated stack Object-shaped stack 63

87 Secondary reference stack Normal stack has no references, second stack has only references C stack Ref stack 64

88 Secondary reference stack Normal stack has no references, second stack has only references foo foo C stack Ref stack foo() 64

89 Secondary reference stack Normal stack has no references, second stack has only references foo foo foo() bar bar bar() C stack Ref stack 64

90 Secondary reference stack Normal stack has no references, second stack has only references foo bar baf C stack foo bar baf Ref stack foo() bar() baf() 64

91 Secondary reference stack Normal stack has no references, second stack has only references foo bar baf C stack foo bar baf Ref stack foo() bar() baf() GC scans only this stack Simply read entire stack: There are only references 64

92 Reference stack caveats Usually needs reference stack register CPU registers are rare! Complicates other parts of compiler, e.g. exception handling 65

93 Parsable stack Like parsable heap: Make sure GC can find info in stack C stack 66

94 Parsable stack Like parsable heap: Make sure GC can find info in stack foo foo() h C stack 66

95 Parsable stack Like parsable heap: Make sure GC can find info in stack foo h bar h C stack foo() bar() 66

96 Parsable stack Like parsable heap: Make sure GC can find info in stack foo h bar h baf h C stack foo() bar() baf() 66

97 Parsable stack caveats Does not play nicely with others (C, C++) 67

98 Heap-allocated stack Every function allocates a stack object, chains those together into pseudo-stack Root Heap 68

99 Heap-allocated stack Every function allocates a stack object, chains those together into pseudo-stack Root Heap foo foo() 68

100 Heap-allocated stack Every function allocates a stack object, chains those together into pseudo-stack Root Heap foo bar foo() bar() 68

101 Heap-allocated stack Every function allocates a stack object, chains those together into pseudo-stack Root Heap baf foo bar foo() bar() baf() 68

102 Heap-allocated stack caveats Stack frames outlive function execution Easy closures! Need descriptors for every possible stack frame Restrictive to compiler 69

103 Object-shaped stack Exactly like heap-allocated stack, but allocate stack frame objects on stack Caveat: GC must expect objects in stack Stack is now a partition 70

104 What is a reference? Thusfar: Reference is pointer to beginning of object Possibilities to consider: Interior pointers Indirect pointers 71

105 Interior pointer struct List { struct List *next; int val; }; void breakthings(struct List *l) { int *nasty = &l->val; l = l->next; // yield to GC printf("%d\n", *nasty); } 72

106 Interior pointers Usual solution: Not allowed When allowed: 1. Get chunk (e.g. card) associated with interior pointer 2. Parse chunk to find containing object 3. If moving, preserve offset 73

107 Object tables Alternative contract between compiler and memory manager Instead of program using (e.g.) struct List * always use (e.g.) struct List ** 74

108 Object tables Accessing object is double-dereference User pointer refers to object table entry, object table entry refers to object. Object table forms its own partition Object table entries don t move 75

109 Object table thoughts Slows down object access Allows atomic object replacement i.e., one object may replace another Makes moving objects simple (only one ref to update) Makes mark-and-compact require only one sweep! 76

110 Runtime interface Important components: Allocation Where references are in roots, objects When collection can occur Barriers on writing to (reading from?) objects 77

111 Any-time collection Threads may be doing anything at any time Can we stop mutator at any time to collect? Think about stack references: Mutator must never deviate from description Very limiting to optimizations 78

112 Yieldpoint collection Compiler adds yieldpoints to allow collection Between yieldpoints, stack in inconsistent state To stop, wait for all threads to reach yeildpoint 79

113 When to yield Mandatory: During allocation, at function calls Optional: At tight loops or other longrunning operations Threads must yield frequently to allow GC to occur promptly 80

114 How to yield Polling: void yield() { if (stoptheworld) collect(); } Patching: Overwrite the yield function with a version that stops the thread 81

115 Runtime interface Important components: Allocation Where references are in roots, objects When collection can occur Barriers on writing to (reading from?) objects 82

116 Write barriers Either reference counting or inter-partition remembering For inter-partition remembering: Guard (check that ref must be remembered) Remember (e.g. write bit for card) 83

117 Write barrier guard write(obj, loc, val): if genof(obj) == old and genof(val) == young: genof isn t cheap (bit math to get pool, read gen from pool header) 84

118 Arranging for better barriers Sometimes can ask for pools at certain locations in memory Approximate generation check with location check Imperfect guard means more remembered set writing, but less time in write barrier 85

119 Sequential heap guard write(obj, loc, val): if obj > val: Write barrier can trigger improperly, but the check is (usually) one CPU operation Young gen must have (pointless) remembered set 86

120 Unguarded write barrier write(obj, loc, val): poolof(obj)->(remember obj) *loc := val All writes more expensive, remembered set less precise, but write time is predictable. 87

121 Runtime interface Summary: Allocation Where references are in roots, objects When collection can occur Barriers on writing to (reading from?) objects 88

122 Presentations Next week we start presentations [If any presentation doesn t happen, I will blather in the interim] I will have some final words on the last day Make sure to talk to me about your final projects! 89