Mastering GC.pdf
1 like934 views
The document discusses various garbage collectors (GCs) in OpenJDK, including Serial GC, Parallel GC, G1 GC, Shenandoah GC, and Z GC, outlining their characteristics and use cases. It highlights how to select and tune GCs based on workload types—throughput-oriented or latency-sensitive—and provides specific tuning strategies for each GC to optimize performance. The conclusion emphasizes the importance of understanding the complexities and potential pitfalls of tuning G1 GC due to its heuristics.
Mastering GC.pdf
- 1. Mastering GC: tame the beast and make it your best ally Jean-Philippe Bempel @jpbempel
- 2. Agenda ● OpenJDK GCs ● Selecting the right GC ● Tuning GC
- 3. OpenJDK GCs
- 4. Serial GC ● Generational ● Single threaded ● Stop-The-World ● Default GC for < 2GB or < 2 cores
- 6. Semi-spaces: Survivors Young Old Eden S0 S1 Young Live objects Dead objects 5 5 1 1
- 7. Parallel GC ● Generational ● Multi threaded ● Stop-The-World
- 8. Minor GC marking Young Old Live objects Dead objects
- 9. Remember Set: Card Table Young 0 0 1 Live objects Dead objects
- 10. G1 GC ● Generational ● Multi threaded ● Stop-The-World/Concurrent ● Region based
- 11. Regions
- 13. ● Memory reclaimed by evacuation of a region (copying objects/compacting) ● Limiting copy and focus on regions with most garbage => G1 ● When evacuating objects, you update refs, but avoid scanning the full heap ● Using RememberSet to know which region to scan for refs Regions
- 14. RememberSet
- 15. Shenandoah GC ● Not generational (single space) ● Fully Concurrent ● Region based
- 16. Concurrent Evacuation: challenges ● How to make sure we can reach an object that is evacuating? ● Read (Load) Barrier ○ Everytime we are loading an object to access it, we check if we need to find it elsewhere or not ● Self-Healing ○ Application thread can help fix addresses not yet fixed by GC threads
- 17. Z GC ● Not generational (yet) ● Fully Concurrent ● Region based
- 18. Colored pointers ● Store metadata in unused bits of reference address ● 44 bits for addressing 16TB (Max Heap) ● 4 bits for metadata: ○ Marked0 ○ Marked1 ○ Remapped ○ Finalizable
- 19. Selecting the right GC
- 20. Identify your workload: Throughput oriented ● Jobs, processing by steps ● High volume of data ● No response to a human user ● Examples: Spark jobs, Kafka consumer/producer, intakes, ETL, …
- 21. Identify your workload: Latency sensitive ● Application based on Request/Response ● Response to human user, even indirect (microservices dependencies) ● Databases ● Examples: Http/gRPC services, Cassandra
- 22. Throughput oriented: Which GC? ● JDK Flight Recorder (JFR) files ● Use JDK Mission Control Library for parsing round robin fashion ● Metric: total runtime of a predefined number of JFR files processed
- 23. Throughput oriented: Which GC?
- 26. Throughput oriented: Analysis Parallel
- 27. Throughput oriented: Analysis Parallel
- 28. Latency sensitive: Which GC? ● Spring petclinic demo app ● Send requests and waiting for response ● Metric: Percentiles of latency of each request
- 29. Latency sensitive: Which GC?
- 30. Latency sensitive: Which GC?
- 31. Tuning GC
- 32. Tuning Parallel GC ● Very simple to reason about ● Main goal: avoid promoting short/middle lived object to postpone Full GC ● Adjust young gen to reach this goal depending on your workload ● Don’t hesitate to increase the young gen sometimes > 50% of the heap
- 34. Tuning G1: Humongous ● Humongous objects are difficult to handle for G1: ○ Creates fragmentation ○ Cannot move ○ Triggers prematurely GC b/c checked during each Humongous alloc ● GC Cause = Humongous allocation ○ Try to adjust HeapRegionSize to reduce Humongous objects ○ But large objects not Humongous need to be moved, may increase pause time… ○ Cannot do if regions are already 32MB…
- 36. Tuning G1: Young Gen Resize ● Resize based on target pause time: ○ Increase if pause time < target ○ Decrease if pause time > target ● Goal overshoot leads to aggressive young gen reduction down to 5%: ○ Short young gen generates very frequent Young GC ○ This storm can lead to over promotion/copy of objects and increase of pause time ○ More frequent GCs + significant pause time => worse than overshooting the initial goal ● Use NewSize/MaxNewSize for min and max Young Gen ○ But not NewRatio or Xmn which will fix the Young Gen
- 37. Tuning G1: Target pause time ● Main knob for G1 to tune is MaxGCPauseMillis as Target Pause time ● Increase target pause for more throughput (accepting more pause time) ● Decrease target pause time for more low latency, but below 50ms it’s difficult…
- 38. Tuning Shenandoah ● To be effective, allocation rate should not overrun the GC ● Otherwise => Pacer or Full GC ● Need heap headroom for having time to collect and reclaim regions ● cores/Conc Gc threads for finishing cycle faster ● Region reclaim is done at the end of the GC cycle
- 39. Tuning Z ● To be effective, allocation rate should not overrun the GC ● Otherwise “Allocation Stall” but No Full GC ● Need heap headroom for having time to collect and reclaim regions ● cores/Conc Gc threads for finishing cycle faster ● Region reclaim is done as soon as relocation is done
- 40. Conclusion
- 41. How to choose a GC? ● Throughput oriented workload ○ Parallel GC ○ G1 if no issue and good figures ● Latency sensitive workload ○ Shenandoah ○ Z ○ C4
- 42. Why not G1? ● Complexity of the heuristic make it difficult to tune ● Couple of things can go wrong: ○ Fragmentation leading to FullGC, not all Old region are considered ○ RememberSet granularity, Post-Write Barrier, Refinement Threads ○ Evacuation failure (=> full GC), InitiatingHeapOccupancyPercent, G1ReservePercent ○ Young Gen dynamic sizing, drastic reduction leads to minor GC storm ○ Humongous allocations, premature minor GC and fragmentation ● G1 Heuristic can save you or can curse you!
- 43. References
- 44. References Understanding low latency GCs G1 One Garbage Collector to rule them all Tips for Tuning The G1 GC G1 Garbage Collector Details and Tuning What’s the deal with humongous objects in Java? Shenandoah: The Garbage Collector That Could Load Reference Barriers Eliminating forward pointer word Concurrent GC collectors: ZGC & Shenandoah Deep Dive into ZGC: A Modern Garbage Collector in OpenJDK GCEasy.io