Download to read offline
Uploaded byKrystian Zybała
New Algorithms in Java
The document discusses various Java garbage collection (GC) algorithms, including G1, Shenandoah, and ZGC, highlighting their functionalities, benefits, and tuning methods. It emphasizes the need for low-pause collectors suitable for diverse applications and addresses the trade-offs involved in achieving low pause times. The document also mentions future developments in GC technology within the Java ecosystem.
![[Jbcn 2016] Garbage Collectors WTF!?](https://cdn.slidesharecdn.com/ss_thumbnails/jbcn2016garbagecollectors-wtf-1-160618101430-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
New Algorithms in Java
- 1. Krystian Zybała @k_zybala (Modern) New?GC algorithms in Java
- 2. # whoami • JavaPrincipal Engineer / Java Performance Engineer • Specialization : JVM, Apache Kafka, Cassandra • Hobby : JVM Performance, Reactive Systems • Workshops, Consultations Twitter: @k_zybala Blog: https://kzybala.pl Mail: kontakt@kzybala.pl
- 3.
- 4. Let's hold ourhands and wait for the next GC cycle
- 5.
- 6. GC is yourfriend 🤗
- 7.
- 8. Previous GC’s algorithms •SerialGC • ParallelGC • CMS - not available in current JDKs builds • G1GC
- 9.
- 10.
- 11. The most ofyoung objects are much more likely to die than old objects
- 12. Eden Survivor 1Survivor 2 Tenured New object Old generation Young generation
- 13.
- 14. G1 • Low-pause collector- First papers date back to 2004 • Supported since JDK 7u4 (April 2012) • Replacement for CMS • Low pauses valued more than max throughput • Designed to be really ease to tune • Tuning based on max Stop-The-World pause ( -XX:MaxGCPauseMillis=X) Default: 250ms
- 15. G1 • Default GCsince Java 9 • Use regions instead generations • Dynamic size of region • Parallel Full GC in Java10(jdk-10-ea+34)
- 16. G1 Concurrent Marking Concurrent liveness summary InitMarking Remark Clean up GC Thread Application Thread Copy or Space reclamation
- 18.
- 19. bool UseG1GC =false {product} {default} bool UseSerialGC = true {product} {ergonomic} http://hg.openjdk.java.net/jdk/jdk10/ fi le/b09e56145e11/src/hotspot/share/runtime/os.cpp#l1606
- 20.
- 21. Why we needsomething new?
- 23. GC Optimized forBest for Pause Multi- threaded Number of cores SerialGC Memory Footprint Single core, small heaps ( micro-service ? ) Yes No 1 ParallelGC Throughput Batch job Yes Yes 2+ G1GC Throughput / Latency Balance request-response db integractions Yes Yes 2+* ZGC Low latency request-response db integractions Yes Yes 2+* ShenandoahGC Low latency request-response db integractions Yes Yes 2+*
- 24. How does itwork?
- 25. How does itwork? • Requires meta data storing in object • Requires JIT support - Load GC barrier or Store GC barrier
- 26. Mutator problems Headers x =1 y = 2 z = 1 Object A Object B
- 27. Mutator problems Headers x =1 y = 2 z = 1 Headers x = 1 y = 2 z = 1 from-space to-space Object A Object B Object A Object B Object C
- 28. Mutator problems Headers x =1 y = 4 z = 1 Headers x = 3 y = 2 z = 1 from-space to-space Application thread 10 Application thread 3 Object A Object B Object A Object B
- 29.
- 30. Shenandoah • Available inAdoptOpenJDK builds • NOT available in Oracle’s OpenJDK builds • Present in RedHat OpenJDK 8,11+ • Low pause GC • Concurrent Compaction, Single Generation
- 31. Shenandoah • Available forx86 32-bit and 64-bit • ARM ports available • Linux, MacOS, Windows • Region Based
- 32. Shenandoah 1.0 * Maintains aweak to-space invariant * Load barrier * Store barrier
- 33.
- 34. Shenandoah Mark Class Field1 Field2 Mark Class Field1 Field2 Mark Class Field1 Field2 Mark Class Field1 Field2 Fwd Ptr FwdPtr 1.0 Object A Object B Object C Object A Object B Object C
- 35. Shenandoah Problems * More memoryneed ( due to the forward pointer) worst case 50% common case 5-10% * Complicated GC barriers ( Store and Load)
- 36. Shenandoah 2.0 * Maintains astrong to-space invariant * Load barrier (LRB - Load Reference Barrier)
- 37.
- 38. Shenandoah 2.0 Class Field1 Field2 Mark Class Field1 Field2 Fwd Ptr Mark Class Field1 Field2 From SpaceTo Space Object A Object B Object C
- 39. Shenandoah Concurrent Mark Concurrent Evacuation Init MarkFinal Mark Init U-R Concurrent Update References GC Thread Application Thread Final U-R
- 40.
- 41. Shenandoah Marking + Evacuating+ Update References
- 42.
- 43. Shenandoah Mark Class Field1 Field2 Evacuation from-space to-space Mark Class Field1 Field2 Application Threadcopy Object A Object B Object B’
- 44. Shenandoah Mark Class Field1 Field2 Evacuation Mark Class Field1 Field2 from-space to-space Mark Class Field1 Field2 GC Threadcopy Application Thread copy Object A Object B Object B’’ Object B’
- 45. Shenandoah Evacuation Mark Class Field1 Field2 from-space to-space Mark Class Field1 Field2 Class Field1 Field2 Fwd Ptr GCThread copy Application Thread copy Object A Object B Object B’’ Object B’
- 46.
- 47.
- 48.
- 49.
- 50. Shenandoah Tuning • -XX:+AlwaysPreTouch •-XX:+UseLargePages • -XX:+UseNUMA (not supported yet) • -XX:-UseBiasedLocking • -XX:+DisableExplicitGC
- 51.
- 52. ZGC • Sub-millisecond maxpause times (less than 10ms) (less than 1ms) • Pauses are O(1) • Pause times do not increase with the heap, live-set or root-set size • Handle heaps ranging from a 8MB to 16TB in size • ZGC was initially introduced as an experimental feature in JDK 11, and was declared Production Ready in JDK 15.
- 53. ZGC • Only forLinux x86 64-bit • compressed class pointers • no support compress OOPs • Region based • ZPages • Small ( 2MiB - object size up to 256KiB) • Medium ( 32MiB - object size up to 4MiB) • Large ( 4+ MiB - object size > 4MiB)
- 54. ZGC • Concurrent • Region-based •Compacting • NUMA-aware • Using colored pointers • Using load barriers
- 55. ZGC Uses colored pointers.Color indicates GC metadata Object address - 44 bits 16 bit 4 color bits 64 bits pointer address
- 56. ZGC Multi-Mapping ∂ ∂ 001<addr> Virtual memory Physicalmemory 010<addr> 100<addr>
- 57. ZGC ZGC uses aload GC barrier Object someObject = person.name; <load_barrier> // String n = person.name; mov 0x10(%rax), %rbx // bad color test %rbx, (0x16)%r15 // If yes, enter slow path jnz slow_path
- 58. ZGC Concurrent Mark Reference processing Unload classes Freememory pages Prepare relocation Mark start Mark End Relocate Concurrent Relocate Concurrent Remap GC Thread Application Thread
- 59. ZGC Concurrent Mark Concurrent Reference processing Unload classes Freememory pages Prepare relocation Concurrent Relocate Remap Concurrent Mark …
- 60.
- 61. ZGC Relocation Forwarding table A ->A1 B -> B1 C -> C1
- 62. ZGC Relocation Forwarding table A ->A1 B -> B1 C -> C1 D -> D1 Application thread copy
- 63. ZGC Relocation Forwarding table A ->A1 B -> B1 C -> C1 D -> D1 Application thread copy GC thread copy
- 64. ZGC Relocation Forwarding table A-> A1 B -> B1 C -> C1 D -> D1 E -> E1 Application thread copy GC thread copy
- 65.
- 66. ZGC Future changed * Generational *Sub-millisecond max pause time * Graal JIT support
- 67.
- 68.
- 69. ZGC Tuning • -XX:ZAllocationSpikeTolerance=factor •-XX:ZCollectionInterval=seconds • -XX:ZFragmentationLimit=percent • -XX:ZUncommitDelay
- 70.
- 71.
- 72.
- 74. JEP 376 ZGC ConcurrentThread-Stack Processing
- 75. Concurrent Thread-Stack Processing ▪Removethread-stack processing from ZGC safepoints. ▪Make stack processing lazy, cooperative, concurrent, and incremental. ▪Remove all other per-thread root processing from ZGC safepoints. ▪Provide a mechanism by which other HotSpot subsystems can lazily process stacks.
- 76.
- 77. Conclusions * Still JDK8? - Shenandoah * JDK 11+ ? - ZGC or Shenandoah * Nothing is for free - you need more resources for achieve low pause
- 78.
- 79. JEP-423 Region Pinningfor G1
- 80. JEP-423 • No stallingof threads due to JNI critical regions. • No additional latency to start a garbage collection due to JNI critical regions. • No regressions in GC pause times when no JNI critical regions are active. • Minimal regressions in GC pause times when JNI critical regions are active.
- 81. Over 30 major performanceimprovements
- 83.
- 84.