Garbage Collection Mythbusters

2. Garbage Collection Mythbusters Simon Ritter Java Technology Evangelist

3. The Goal Cover the strengths and weaknesses of garbage collection What GC does well And what not so well

4. Tracing GC: A Refresher Course Tracing-based garbage collectors: Discover the live objects All objects transitively reachable from a set of “roots” (“roots” - known live references that exist outside the heap, e.g., thread stacks, virtual machine data) Deduce that the rest are dead Reclaim them An “indirect” GC technique Examples Mark & Sweep Mark & Compact Copying

5. Tracing GC Example Heap RuntimeStack A C G K D H B E I L F J M

6. Tracing GC Example The Runtime Stack is considered live by default. We starttracing transitively from it and mark objects we reach. Heap RuntimeStack C G K A H D B E I L F J M

7. Tracing GC Example Heap RuntimeStack A C G K D H B E I L F J M

8. Tracing GC Example Heap RuntimeStack A C G K D H B E I L F J M

9. Tracing GC Example We identified all reachable objects. We can deduce thatthe rest are unreachable and, therefore, dead. Heap RuntimeStack A C G K D H B E I L F J M

10. Alternative 1: In-place Deallocation Keep track of the free space explicit (using free lists,a buddy system, a bitmap, etc.). Heap RuntimeStack A C K H B E I L

11. Alternative 2: Sliding Compaction Slide all live objects to one end of the Heap. All free spaceis located at the other end of the heap. Heap RuntimeStack A C K H B E I L

12. Copying GC Example Heap (From-Space) RuntimeStack A C G K D H B E I L Heap (To-Space)

13. Copying GC Example Heap (From-Space) RuntimeStack C G K A D H B E I L Heap (To-Space) A C

14. Copying GC Example Heap (From-Space) RuntimeStack C G K A D H B E I L Heap (To-Space) A C H K

15. Copying GC Example Heap (From-Space) RuntimeStack C G K A D H B E I L Heap (To-Space) A C H K L B

16. Copying GC Example Heap (From-Space) RuntimeStack G A C K D H B E I L Heap (To-Space) A C H K L B E I

17. Copying GC Example Heap (From-Space) RuntimeStack Heap (To-Space) A C H K L B E I

18. Myth 1:malloc/free always perform better than GC.

19. Object Relocation GC enables object relocation, which in turn enables Compaction: eliminates fragmentation Generational GC: decreases GC overhead Linear Allocation: best allocation performance Fast path: ~10 native instructions, inlined, no sync top new top end new object free space used space

20. Generational GC is Fast! Compare costs (first-order approximation) malloc/free: all_objects * costmalloc + freed_objects * costfree Generational GC with copying young generation: all_objects * costlinear_alloc + surviving_objects * costcopy Consider: costlinear_alloc much less than costmalloc surviving_objects often 5% or less of all_objects

21. GC vs. malloc Study Recent publication shows When space is tight malloc/free outperform GC When space is ample GC can match (or better) malloc/free GC just as fast if given “breathing room” Matthew Hertz and Emery Berger Quantifying the Performance of Garbage Collection vs. Explicit Memory Management, In Proceedings of OOPSLA 2005, October 2005

22. Object Relocation: Other Benefits Compaction: can improve page locality Fewer TLB misses Cluster objects to improve locality Important on NUMA architectures Relocation ordering: can improve cache locality Fewer cache misses The important points: Allocation and reclamation are fast Relocation can boost application performance

23. Myth 1:malloc/free always perform better than GC.

24. Myth 1:malloc/free always perform better than GC. Busted!

25. Myth 2:Reference counting would solve all my GC problems.

26. Reference Counting Each object holds a count How many references point to it Increment it when a new reference points to the object Decrement it when a reference to the object is dropped When reference count reaches 0 Object is unreachable It can be reclaimed A “direct” GC technique

27. Reference Counting Example Heap RuntimeStack 1 2 1 A C K 1 H 1 1 2 1 E I L B 1 1 1 F J M

28. Reference Counting Example Delete reference,Decrease H's RC Heap RuntimeStack 1 2 1 A C K 1 H 1 1 2 1 B E I L 1 1 1 F J M

29. Reference Counting Example Heap RuntimeStack 1 2 1 A C K 0 H 1 1 2 1 E I L B 1 1 1 F J M

30. Reference Counting Example Decrease K's & L's RCs,Reclaim H Heap RuntimeStack 1 2 1 A C K 0 H 1 1 2 1 B E I L 1 1 1 F J M

31. Reference Counting Example Heap RuntimeStack 1 2 0 A C K 1 1 1 1 E I L B 1 1 1 F J M

32. Reference Counting Example Reclaim K Heap RuntimeStack 1 2 0 A C K 1 1 1 1 E I L B 1 1 1 F J M

33. Reference Counting Example Heap RuntimeStack 1 2 A C 1 1 1 1 E I L B 1 1 1 F J M

34. Traditional Reference Counting Extra space overhead One reference count per object Extra time overhead Up to two reference count updates per reference field update Very expensive in a multi-threaded environment Non-moving Fragmentation Not always incremental or prompt Garbage cycles Counts never reach 0 Cannot be reclaimed

35. Reference Counting Example Objects F and J form a garbage cycle and also retain M too. Heap RuntimeStack 1 2 A C 1 1 1 1 E I L B 1 1 1 F J M

36. Advanced Reference Counting Two-bit reference counts Most objects pointed to by one or two references When max count (3) is reached Object becomes “sticky” Buffer reference updates Apply them in bulk Combine with copying GC Use a backup GC algorithm Handle cyclic garbage Deal with “sticky” objects Typically, the cyclic GC is a tracing GC Complex, and still non-moving

37. Myth 2:Reference counting would solve all my GC problems.

38. Myth 2:Reference counting would solve all my GC problems. Busted!

39. Myth 3:GC with explicit deallocation would drastically improve performance.

40. GC with Explicit Deallocation? Philosophically Would compromise safety Practically Not all GC algorithms can support it Mark-Compact & Copying GCs Do not maintain free lists Reclaim space by moving live objects Overwrite reclaimed objects No way to reuse space from a single object Unless the object is at the end of the heap

41. GC with Explicit Deallocation? (ii) Explicit deallocation is incompatible with this model Would compromise the very fast allocation path GCs have a different reclamation pattern Reclaim objects in bulk Free-space management is optimized for that Also applies to static analysis techniques They can prove that an object can be safely deallocated …but there is no mechanism to do the deallocation!

42. How to deallocate? How can we deallocate the dead object when we only maintain top? top end dead object free space used space

43. Myth 3:GC with explicit deallocation would drastically improve performance.

44. Myth 3:GC with explicit deallocation would drastically improve performance. Busted!

45. Myth 4:Finalizers can (and should) be called as soon as objects become unreachable.

46. Finalizers Typical use of Finalizers: Reclaim external resources associated with objects in heap e.g., native GUI components (windows, color maps, etc.) Finalizers are called on objects that GC has found to be garbage Tracing GC Does not always have liveness information for every object Liveness information up to date only at certain points Immediately after a tracing cycle Must finish a tracing cycle to find finalizable objects

47. Finalization Reality Check Finalizers are not like C++ destructors No guarantees When they will be run Which thread will run them Which will run first, second, … last Or that they will be run at all! If you want prompt external resource reclamation Don't rely on finalizers Dispose explicity instead Use finalization as a safety net

48. Myth 4:Finalizers can (and should) be called as soon as objects become unreachable.

49. Myth 4:Finalizers can (and should) be called as soon as objects become unreachable. Busted!

50. Myth 5:Garbage collection eliminates all memory leaks