Garbage Collection in Hotspot JVM
•
4 likes•314 views
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.
Report
Share
Garbage Collection in Hotspot JVM
- 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.
- 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
- 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.
- 71. Stop-the-world.
- 72. Young : Copying
- 73. Old : Mark-sweep-compact (same as Serial).
- 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.
- 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)