The document discusses memory management and garbage collection in the Hotspot Java Virtual Machine. It describes different garbage collection algorithms like mark-sweep, copying, and generational collection. It explains the different garbage collectors in Hotspot JVM like serial, parallel, parallel compacting, and concurrent mark sweep collectors. It also discusses some key garbage collection terminology and metrics.

1. Memory Management In Hotspot VM (GarbageCollection) Jaganmohan Reddy

2. Explicit Memory Management malloc/new allocates space for an object free/delete returns memory to system Forget to free -> memory leak

3. Free too soon -> “dangling pointer”

4. Garbage Collection "Heap storage for objects is reclaimed by an automatic storage management system (typically a garbage collector); objects are never explicitly deallocated."

5. — Java Virtual Machine Specification, Section 3.5.3 [JVMS2 1999]

6. An object that is still referenced somewhere will never be garbage collected

7. Automatically frees all memory no longer referenced

8. Garbage Collector Allocating memory

9. Ensuring that any referenced objects remain in memory

10. Recovering memory used by objects that are no longer reachable from references in executing code

11. Solves many but not all, create objects indefinitely and continue referencing them.

12. Garbage Collection Algorithm Garbage Object Detection Live Object (referenced)

13. Dead Object (not referenced) Garbage Objects Heap memory reclaim

14. Design Choices Serial Vs Parallel.

15. Concurrent Vs Stop-the-world.

16. Compacting Vs Non Compacting Vs Copying.

17. Interactive Vs Non interactive apps.

18. Performance Metrics Throughput —the percentage of total time not spent in garbage collection, considered over long periods of time.

19. Garbage collection overhead —the inverse of throughput, that is, the percentage of total time spent in garbage collection.

20. Pause time —the length of time during which application execution is stopped while garbage collection is occurring.

21. Frequency of collection —how often collection occurs, relative to application execution.

22. Footprint —a measure of size, such as heap size.

23. Promptness —the time between when an object becomes garbage and when the memory becomes available.

24. Reachability Roots – reference to object in a static variable or local variable on an active stack frame

25. Root Objects – directly reachable from roots

26. Live Objects – all objects transitively reachable from roots

27. Garbage Objects – all other objects

28. Reachability Example Runtime Stack ref ref Heap   

29. GC Approaches Two basic approaches: Reference Counting – keep a count of references to an object; when a count of zero, object is garbage Tracing – trace out the graph of objects starting from roots and mark; when complete, unmarked objects are garbage mark phase – GC traverses reference tree, marking objects

30. sweep phase – unmarked objects are finalized/freed

31. Garbage Collection Algorithms Reference Counting algorithm

32. Mark-and-sweep algorithm

33. Copying algorithm

34. Mark-and-Compacting algorithm

35. Generational algorithm

36. Reference Counting Add a reference count field for every object and manipulate whenever number of references change.

37. An early GC strategy

38. Advantages: can be run in small chunks of time Disadvantages: does not detect cycles

39. overhead in incrementing/decrementing counters

40. Mark - Sweep Root      1. mark-sweep start  Root         2. end of marking Root 3. end of sweeping

41. Mark – Sweep Contd. Problem is fragmentation of memory

42. Two strategies include: Mark-Compact Collector – After mark, moves live objects to a contiguous area in the heap

43. Copy Collector – moves live objects to a new area

44. Mark - Compact proportional to the size of the heap  Root         1. end of marking Root 2. end of compacting

45. Copy Collector proportional to the number of live objects Root      1. copying start Root 2. end of copying Unused Unused From From To To

46. Weak generational hypothesis Two very interesting Observations Most allocated objects are not referenced (considered live) for long, that is, they die young.

47. Few references from older to younger objects exist Called Weak generational hypothesis

48. Generational Heap is split into generations, one young and one old

49. Young generation all new objects are created here.

50. Majority of GC activity takes place here and is usually fast (Minor GC).

51. Time intensive Old generation long lived objects are promoted (or tenured) to the old generation.

52. Fewer GC’s occur here, but when they do, it can be lengthy (Major GC).

53. Space intensive.

54. Sun Hotspot Heap Layout Young Old Permanent Eden From To Survivor Spaces

55. Before Minor GC  Old Permanent Eden From To Survivor Spaces         Unused  Young

56. After Minor GC Empty Old Permanent Eden To From Survivor Spaces Unused Young

57. Local Allocation Blocks For multi threaded applications, allocation operations need to be multithread-safe.

58. Global locks degrade performance. nextLAB LAB LAB LAB LAB LAB manager thread thread thread

59. Hostspot Garbage Collectors Four garbage collectors as of J2SE 5.0.

60. All are Generational. Collector GC Used Serial “ Serial" + "Serial Old" Parallel (Throughput) "Parallel" + "Serial Old" Parallel Compaction "Parallel" + "Parallel Old" Concurrent Mark-Sweep (Low Pause) "ParNew" + "CMS”

61. Terminology mutator collector User program Parallel collection Incremental collection Concurrent collection Single threaded collection

62. Serial Collector Young and old collections are done serially.

63. Single threaded.

64. Stop-the-world.

65. Choice for client style machines.

66. Young : Copying.

67. Old : Mark-sweep-compact. Sliding compaction : sliding the live objects towards the beginning of the old generation space. -XX:+UseSerialGC

68. Parallel collector Also called throughput collector.

69. Choice for server class machines.

70. Multi threaded GC.

71. Stop-the-world.

72. Young : Copying

73. Old : Mark-sweep-compact (same as Serial).

74. -XX:+UseParallelGC

75. Serial vs. Parallel Collector stop-the-world pause Serial Collector Parallel Collector

76. Parallel Compacting Collector Young Generation – Same as Parallel

77. Old Generation – Parallel Compaction each generation is logically divided into fixed-sized regions.

78. Live objects are marked in parallel, updates size and location.

79. examine the density of the regions (which region is bigger). -XX:+UseParallelOldGC

80. Parallel compacting Collector Old Generation – Parallel Compaction Mark Phase Summary phase Compaction phase

81. CMS Collector Young Generation – Same as Parallel

82. Old Generation Identify initial set of live objects.

83. Marks all live objects that are transitively reachable from this set concurrently.

84. App is running, all live objects are not guaranteed.

85. Revisiting any objects that were modified during the concurrent marking phase.

86. Sweep -XX:+UseConcMarkSweepGC

87. CMS Collector Non compacting Collector.

88. Maintain free list, allocation is expensive.

89. may split or join free blocks to meet demand. Initial Mark Phase Concurrent Mark Phase Remark phase Concurrent sweep phase

90. CMS Collector stop-the-world pause Mark-Sweep-Compact Collector Concurrent Mark-Sweep Collector initial mark concurrent marking remark concurrent sweeping

91. Heap tuning Analyze application under realistic load

92. Run with –verbose:gc and other options to identify GC information

93. Select GC engine based on need

94. Size areas of heap based on application profile – e.g., an app that creates many temporary objects may need a large eden area

95. Conclusion GC can be your friend (or enemy)

96. Object creation is cheap but GC is not cheap.

97. Put your app on an Object diet

98. Should always monitor an app with -verbose:gc -XX:+PrintGCDetails

99. Tune your heap only if there is a problem

100. A large heap may slow an app (more memory is not always good)