CS842: Automatic Memory Management and Garbage Collection. GC basics

Transcription

1 CS842: Automatic Memory Management and Garbage Collection GC basics 1

2 Review Noting mmap (space allocated) Mapped space Wile owned by program, manager as no reference! malloc (object created) Never returned to S! Free object Pointer eld by program Memory manager Program free (object disowned) 2

3 Automatic memory management Defining principle: free() is automatic Common solution: Garbage collector Part of te runtime does free() for you ter solutions exist (e.g. type-based) We focus on GC 3

4 GC glossary Collector Mutator Heap vs. C eap Pool Root Reference Reacable Type information Stop-te-world Pause Parallel Concurrent 4

5 Performance Many ways of measuring performance: Trougput Resource utilization Responsiveness Fairness Latency Mut. GC Time 5

6 Performance consideration Manual memory management ain t free! 6

7 Performance GC tecnique affects performance Application affects performance Environment affects performance 5% improvement is te GC mantra (GC sould take negative time by now) 7

8 Wen to free? Wat we want: Free an object wen we re done wit it Wat does done mean? Wat we do: Free an object wen it s unreacable 8

9 Reacable? bj bj bj bj bj bj 9

10 Reacable? bj bj bj bj bj bj 10

11 Reacable? bj bj bj Reacability starts from outside our eap bj bj bj 10

12 Reacable? bj bj bj Reacability starts from outside our eap bj bj bj Must know were objects ave references (pointers into te GC eap) 10

13 Aside: Can we do better? Easy to leak memory: static List<bject> everybjectiveeverallocated; No longer in use alting problem Fear not te alting problem: Liveness analysis is very real! But not general. 11

14 Roots 0x0 Program + Static Heap Free Stack 0xFFFF Static Created by compiler Controlled by runtime (GC or not) Dynamic Defined by compiler 12

15 Roots Roots 0x0 Program + Static Heap Free Stack 0xFFFF Static Created by compiler Controlled by runtime (GC or not) Dynamic Defined by compiler 12

16 Te compiler conundrum Roots are full of stuff (Program code, non-reference variables, unused space ) To test reacability, we need references! Compiler must cooperate wit GC: Tell te GC were references exist in roots 13

17 Stack references Split stack: ; need 8 bytes stack sub $8, %rsp ; and 8 bytes ; pointer stack sub $8, %rbp Marked stack: ; need 16 bytes sub $16, %rsp ; tell GC about ; pointers mov $8, %rax call pusgcpointers 14

18 Conservativism Some languages just won t play nice (I m looking at you, C) We can at least guess were tere are pointers 15

19 Heap references malloc(size) isn t enoug! We need references! Need no more type information tan tat Crucial runtime type info: Pointer bitmap Extend eader wit pointer to type info 16

20 Allocation w/ type info struct bjectheader { struct GCTypeInfo *typeinfo; }; void *allocate(struct GCTypeInfo *typeinfo) { size_t size = typeinfo->size; // allocate as usual retheader->typeinfo = typeinfo; return ret; } 17

21 Aside: Alignment Most systems require word-aligned pointers It terefore makes sense to word-align objects We only care about pointers, so only need one bit per word type info 18

22 Heap references class IntList { IntList next; int val; }; 19

23 Heap references class IntList { IntList next; int val; }; Compiler next val - 1 word.5w 2 words.5w 19

24 Heap references class IntList { IntList next; int val; }; Compiler struct GCTypeInfo { size_t size; unsigned long pointermap; }; next val - Compiler new GCTypeInfo(16, 0b1000 ); 1 word.5w 2 words.5w 19

25 Aside: Dynamic type info All types known statically: Static type info Wat about types loaded at runtime? Type info object can be stored in te eap! 20

26 Aside: Dynamic type info Hdr List 21

27 Aside: Dynamic type info Hdr List Hdr Type info for List 21

28 Aside: Dynamic type info Hdr List Hdr Type info for List Hdr Type info for type info 21

29 Aside: Dynamic type info Hdr List Hdr Type info for List Hdr Type info for type info 21

30 Breater Reacability Start wit roots Compiler tells us references from roots Type info tells us references from objects 22

31 Garbage collection We ve determined wat is reacable Wat isn t reacable is garbage! But it s not reacable So ow do we free it? 23

32 Parsable eap A eap is parsable if we can walk troug all objects in it Parsability broken by gaps, lacking info or bugs 24

33 Parsable eap F F struct Pool { struct Freebject *freebjects; void *freespace; }; 25

34 Collection Wile parsing te eap, ow to tell wic objects were unreacable? Add a mark field to eaders, mark objects wic are reaced Unmarked objects are unreacable, so freed. 26

35 Mark and sweep Tat s it! Now we ave a mark and sweep garbage collector! (it would be competitive in 1974) 27

36 Moving 28

37 Moving 28

38 Moving Everyting tat remains is garbage! 28

39 Moving Everyting tat remains is garbage! 28

40 Moving Tis part takes some effort Everyting tat remains is garbage! 28

41 Moving Must be able to update all references Compiler tells us about references anyway But isn t moving memory expensive? 29

42 Lifetime principles Most objects die young Terefore, more valuable to save time on (plentiful) dead objects tan (few) living ones Moving can be wort it 30

43 Stop-te-world Wen do we scan? If mutator still running, we can miss references So, stop te (mutator s) world before GC Compiler implication: Yieldpoints 31

44 Yieldpoint Mutator runs GC not needed Mutator runs GC not needed Mutator runs GC Wait Mu r 32

45 Less stopping Incremental: Do some GC work eac time Difficulty: Hard to do alf of reacability Concurrent: Do GC simultaneous wit mutator work Difficulty: Communicating reference canges 33

46 Summary Compiler tells us roots Compiler tells us wen we can collect Find reacable objects Discard unreacable objects 34