2025-03-11 Trash Talk by Gerrit Grunwald

Transcript

1. EXPLORING THE MEMORY MANAGEMENT IN THE JVM G1 Epsilon CMS Parallel ZGC Serial Shenandoah C4 Epsilon
2. Gerrit Grunwald | Developer Advocate | Azul @hansolo.eu ABOut me.
3. MemOry MAnAgement
4. in the JVM...
5. is autOma tic right...?
6. SO...why care...?
7. MEMORY MANAGEMENT Why you should care... Impact on application performance
8. MEMORY MANAGEMENT Why you should care... Impact on application performance Impact on application responsiveness
9. MEMORY MANAGEMENT Why you should care... Impact on application performance Impact on application responsiveness Impact on system requirements
10. Stack, Heap and Metaspace MEMORY MANAGEMENT Grows/Shrinks Dynamically Local access -> thread safe THREAD STACK FRAME Primitives References FRAME Primitives References FRAME Primitives References FRAME Primitives References
11. Stack, Heap and Metaspace MEMORY MANAGEMENT Grows/Shrinks Dynamically Local access -> thread safe Shared access -> Not thread safe Needs Garbage Collection THREAD STACK FRAME Primitives References FRAME Primitives References FRAME Primitives References FRAME Primitives References HEAP Objects
12. Stack, Heap and Metaspace MEMORY MANAGEMENT Grows/Shrinks Dynamically No fi xed size, grows dynamically Local access -> thread safe Shared access -> Not thread safe Needs Garbage Collection Contains info needed for JVM to work with classes THREAD STACK FRAME Primitives References FRAME Primitives References FRAME Primitives References FRAME Primitives References HEAP Objects METASPACE Class Metadata Constant Pool Method bytecode
13. Stack, Heap and Metaspace MEMORY MANAGEMENT Grows/Shrinks Dynamically No fi xed size, grows dynamically Local access -> thread safe Shared access -> Not thread safe Needs Garbage Collection Contains info needed for JVM to work with classes THREAD STACK FRAME Primitives References FRAME Primitives References FRAME Primitives References FRAME Primitives References HEAP Objects METASPACE Class Metadata Constant Pool Method bytecode StackOver fl owError OutOfMemoryError
14. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit } MEMORY MANAGEMENT In the JVM...
15. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = ref Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = ref
16. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = ref Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = ref Heap area Person object p1 Person object p2 Person object p3 Person object p4 List object
17. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = ref Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = ref Heap area Person object p1 Person object p2 Person object p3 Person object p4 List object All 4 persons and the list are reachable
18. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit p1 = null; } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = null Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = ref Heap area Person object p1 Person object p2 Person object p3 Person object p4 List object Setting p1 = null
19. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit p1 = null; System.out.println(persons.get(0)); // -> Gerrit } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = null Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = ref Heap area Person object p1 Person object p2 Person object p3 Person object p4 List object Person 1 is still reachable via the persons list
20. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit p1 = null; System.out.println(persons.get(0)); // -> Gerrit persons = null; } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = null Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = null Heap area Person object p1 Person object p2 Person object p3 Person object p4 List object Setting persons = null
21. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit p1 = null; System.out.println(persons.get(0)); // -> Gerrit persons = null; } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = null Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = null Heap area Person object p1 Person object p2 Person object p3 Person object p4 List object Only p2, p3 and p4 are reachable
22. public static void main(String[] args) { record Person(String name) { @Override public String toString() { return name(); } } Person p1 = new Person("Gerrit"); Person p2 = new Person("Sandra"); Person p3 = new Person("Lilli"); Person p4 = new Person("Anton"); List<Person> persons = Arrays.asList(p1, p2, p3, p4); System.out.println(p1); // -> Gerrit p1 = null; System.out.println(persons.get(0)); // -> Gerrit persons = null; } MEMORY MANAGEMENT In the JVM... Stack for thread 1 Frame for main Person p1 = null Person p2 = ref Person p3 = ref Person p4 = ref List<Person> persons = null Heap area Person object p1 Person object p2 Person object p3 Person object p4 List object p1 and persons are garbage
23. HOW tO get rid OF it...?
24. GArbAge COllectiOn
25. GARBAGE COLLECTION What is it... Form of automatic memory management
26. GARBAGE COLLECTION What is it... Form of automatic memory management Identi fi es and reclaims no longer used memory
27. GARBAGE COLLECTION What is it... Form of automatic memory management Identi fi es and reclaims no longer used memory Ensures ef fi cient memory utilisation
28. GARBAGE COLLECTION What is it... Form of automatic memory management Identi fi es and reclaims no longer used memory Ensures ef fi cient memory utilisation Frees user from managing the memory manually
29. cOnserv A tive And Precise
30. GARBAGE COLLECTION Conservative and Precise Conservative does not fully identify all object references (assumes any bit pattern in memory could be a reference, lead to more false positives)
31. GARBAGE COLLECTION Conservative and Precise Conservative does not fully identify all object references (assumes any bit pattern in memory could be a reference, lead to more false positives) Precise correctly identi fi es all references in an object (needed in order to move objects)
32. PHASeS (precise collectors)
33. GARBAGE COLLECTION Phases (precise collectors) Tracing Identify live objects on the heap
34. GARBAGE COLLECTION Phases (precise collectors) Tracing Identify live objects on the heap Freeing Reclaim resources held by dead objects
35. GARBAGE COLLECTION Phases (precise collectors) Tracing Identify live objects on the heap Freeing Reclaim resources held by dead objects Compaction Periodically relocate live objects
36. StOPping the WORLD
37. STOPPING THe W RLD Halt of all application threads Application Threads Application Threads GC Threads JVM Safe Point Safe Point Signal
38. COllectOrs
39. NOn mOving cOllectOr Mark & Sweep
40. NON MOVING COLLeCTOR Free Cell Referenced Cell Dereferenced Cell Marked Cell 1 Referenced Cell (survived 1 GC) Demo 1. Mutator allocates cells in Heap 2. Heap is out of memory -> GC 3. Mark all live cells 4. Free all dead cells 5. Unmark all live cells 6. Resume Mutator 􀇾 Fragmentation
41. MOving COLLeCTORs Compacting Collector & Copy Collector
42. cOmpActing COLLeCTOR Mark & Compact
43. COMPACTING COLLeCTOR Demo Free Cell Referenced Cell Dereferenced Cell Marked Cell 1 Referenced Cell (survived 1 GC) 1. Mutator allocates cells in Heap 2. Heap is out of memory -> GC 3. Mark all live cells 4. Free all dead cells 5. Unmark all live cells 6. Compact all live cells 7. Resume Mutator 􀇾 Headroom 20-50%
44. COpy COLLeCTOR Mark & Copy
45. To Space From Space Demo COpy COLLeCTOR Free Cell Referenced Cell Dereferenced Cell Marked Cell 1 Referenced Cell (survived 1 GC) 1. Allocating in ToSpace 2. ToSpace is out of memory -> GC 3. Toggle To- and FromSpace 4. Mark live cells in FromSpace 5. Copy live cells to ToSpace 6. Free all cells in FromSpace 7. Resume Mutator 􀇾 Long living objects and twice as much memory
46. GenerA tiOnAl COLLeCTOR Generational Mark & Compact
47. GenerA tiOnAl COLLeCTOR Weak Generational Hypothesis (Most objects die young) medium living short living long living LIFETIME OF OBJECTS NUMBER OF OBJECTS
48. medium living short living long living medium living short living long living Weak Generational Hypothesis (Most objects die young) LIFETIME OF OBJECTS NUMBER OF OBJECTS Major collection Minor collection Survivor Spaces Eden Tenured Space Old Generation Young Generation Full collection Eden space for short living objects (can be collected quickly) Survivor spaces for medium living objects Tenured space for long living objects GenerA tiOnAl COLLeCTOR
49. GenerA tiOnAl COLLeCTOR Eden Space To Space From Space Tenured Space Young Generation Old Generation Demo Free Cell Referenced Cell Dereferenced Cell Marked Cell 1 Referenced Cell (survived 1 GC) 1. Mutator allocates cells in Eden 2. Eden is out of memory -> GC 3. Toggle To- and FromSpace 4. Copy all live cells from FromSpace to ToSpace 5. Copy all live cells from Eden to ToSpace 6. Promote live cells from FromSpace to TenuredSpace 7. Free all dead cells 8. Resume Mutator
50. Remembered Set Intergenerational References
51. remembered set How to do a minor collection with references from old to young generation...?
52. remembered set Also known as Card Table Free Cell Referenced Cell Dereferenced Cell Marked Cell Roots Old Generation Young Gen
53. Free Cell Referenced Cell Dereferenced Cell Marked Cell Roots Old Generation Young Gen Minor GC remembered set Also known as Card Table
54. Free Cell Referenced Cell Dereferenced Cell Marked Cell Roots Old Generation Young Gen Minor GC remembered set Also known as Card Table
55. Free Cell Referenced Cell Dereferenced Cell Marked Cell Roots Old Generation Young Gen Minor GC remembered set Also known as Card Table
56. Free Cell Referenced Cell Dereferenced Cell Marked Cell Roots Old Generation Young Gen Minor GC remembered set Also known as Card Table
57. Free Cell Referenced Cell Dereferenced Cell Marked Cell ? Roots Old Generation Young Gen Minor GC remembered set Also known as Card Table
58. Free Cell Referenced Cell Dereferenced Cell Marked Cell ? Roots Old Generation Young Gen 0 1 0 0 Marked in Card Table Minor GC remembered set Also known as Card Table
59. Free Cell Referenced Cell Dereferenced Cell Marked Cell Roots Old Generation Young Gen 0 1 0 0 Marked in Card Table GC looks up Card Table, fi nds the reference and marks it as live Minor GC remembered set Also known as Card Table
60. CONCURReNT COLLeCTION ?
61. CONCURReNCY IS HARD...
62. CONCURReNT MARKING
63. CONCURReNCY IS HARD... Concurrent Marking Not visited Live Reachable Root
64. Not visited Live Reachable Root Concurrent Marking Collector starts marking objects CONCURReNCY IS HARD...
65. Not visited Live Reachable Root Concurrent Marking CONCURReNCY IS HARD...
66. Not visited Live Reachable Root Concurrent Marking Mutator removes reference and creates a new one from an already visited cell ! App. Thread CONCURReNCY IS HARD...
67. Not visited Live Reachable Root Concurrent Marking Mutator removes reference and creates a new one from an already visited cell ! App. Thread CONCURReNCY IS HARD...
68. CONCURReNCY IS HARD... Not visited Live Reachable Root 􀇾 Concurrent Marking Won't be detected by the Garbage Collector !
69. Not visited Live Reachable Root 􀇾 Won't be detected by the Garbage Collector ! Concurrent Marking CONCURReNCY IS HARD...
70. ???
71. BARRIeRS TO THe ReSCUe
72. bArriers Read / Write Barriers Mechanisms to execute memory management code when a read/write on some object takes place
73. bArriers Read / Write Barriers Mechanisms to execute memory management code when a read/write on some object takes place Used to keep track of inter-generational references. (references from old generation to young generation, the so called Rembered Set)
74. bArriers Read / Write Barriers Mechanisms to execute memory management code when a read/write on some object takes place Used to keep track of inter-generational references. (references from old generation to young generation, the so called Rembered Set) Used to synchronize action between mutator and collector (allocation concurrent to collection)
75. bArriers Read / Write Barriers Mechanisms to execute memory management code when a read/write on some object takes place Used to keep track of inter-generational references. (references from old generation to young generation, the so called Rembered Set) Used to synchronize action between mutator and collector (allocation concurrent to collection) Read Barriers are usually more expensive (reads 75% to writes 25% -> Read Barriers must be very ef fi cient)
76. CONCURReNCY IS HARD... Not visited Live Reachable Root Concurrent Marking using Write Barriers
77. Not visited Live Reachable Root Collector starts marking objects Concurrent Marking using Write Barriers WB CONCURReNCY IS HARD...
78. Not visited Live Reachable Root WB Concurrent Marking using Write Barriers WB CONCURReNCY IS HARD...
79. Not visited Live Reachable Root WB Mutator hits write barrier and removes reference and adds a new one Concurrent Marking using Write Barriers WB App. Thread CONCURReNCY IS HARD...
80. Not visited Live Reachable Root WB Mutator hits write barrier and removes reference and adds a new one Concurrent Marking using Write Barriers WB App. Thread CONCURReNCY IS HARD...
81. Not visited Live Reachable Root WB Removed references will be marked as reachable by Write Barrier Concurrent Marking using Write Barriers WB WB CONCURReNCY IS HARD...
82. Not visited Live Reachable Root Concurrent Marking using Write Barriers WB WB WB WB CONCURReNCY IS HARD...
83. Not visited Live Reachable Root Concurrent Marking using Write Barriers WB WB WB WB WB CONCURReNCY IS HARD...
84. Not visited Live Reachable Root Concurrent Marking using Write Barriers WB WB WB WB WB WB WB CONCURReNCY IS HARD...
85. Not visited Live Reachable Root Concurrent Marking using Write Barriers WB WB WB WB WB WB WB WB CONCURReNCY IS HARD...
86. Not visited Live Reachable Root Concurrent Marking using Write Barriers WB WB WB WB WB WB WB WB CONCURReNCY IS HARD...
87. Not visited Live Reachable Root In the Re-Marking phase, in between marked references will be marked as live Concurrent Marking using Write Barriers WB WB WB WB WB WB WB WB CONCURReNCY IS HARD...
88. Not visited Live Reachable Root In the Re-Marking phase, in between marked references will be marked as live Concurrent Marking using Write Barriers WB WB WB WB WB WB WB WB CONCURReNCY IS HARD...
89. CONCURReNT COPYING
90. Stop the world copying HEADERS x = 1 y = 2 Z = 3 FROM Space References TO Space CONCURReNCY IS HARD...
91. HEADERS x = 1 y = 2 Z = 3 STOP Stop the World (the Mutator) References Stop the world copying FROM Space TO Space CONCURReNCY IS HARD...
92. HEADERS x = 1 y = 2 Z = 3 STOP Copy the Object (Create forwarding pointer) References Stop the world copying FROM Space TO Space HEADERS x = 1 y = 2 Z = 3 CONCURReNCY IS HARD...
93. FORWARDING x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 STOP Update all references (Save the pointer that fowards the copy) References Stop the world copying FROM Space TO Space CONCURReNCY IS HARD...
94. FORWARDING x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 STOP Update all references (Walk the heap and replace all references with forwarding pointer to new location) References Stop the world copying FROM Space TO Space CONCURReNCY IS HARD...
95. FORWARDING x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 STOP Update all references (Walk the heap and replace all references with forwarding pointer to new location) References Stop the world copying FROM Space TO Space CONCURReNCY IS HARD...
96. HEADERS x = 1 y = 2 Z = 3 Remove old objects and continue running the Mutator References Stop the world copying FROM Space TO Space CONCURReNCY IS HARD...
97. HEADERS x = 1 y = 2 Z = 3 References Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
98. HEADERS x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 While copying the Object... Concurrent copying FROM Space TO Space References CONCURReNCY IS HARD...
99. HEADERS x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 While copying the Object... Concurrent copying FROM Space TO Space References CONCURReNCY IS HARD... FORWARDING
100. HEADERS x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 ...when updating the references... References Concurrent copying FROM Space TO Space CONCURReNCY IS HARD... FORWARDING
101. HEADERS x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 ...both Objects are reachable ! Concurrent copying FROM Space TO Space References CONCURReNCY IS HARD... FORWARDING
102. x = 1 y = 2 Z = 3 HEADERS x = 1 y = 2 Z = 3 HEADERS ...both Objects are reachable ! And can be accessed in parallel by different Threads. Concurrent copying FROM Space TO Space References CONCURReNCY IS HARD... FORWARDING
103. x = 1 y = 5 Z = 3 HEADERS x = 4 y = 2 Z = 3 HEADERS Threads can write to both Objects ! Thread B Thread A Concurrent copying FROM Space TO Space References CONCURReNCY IS HARD... FORWARDING
104. x = 1 y = 5 Z = 3 HEADERS x = 4 y = 2 Z = 3 HEADERS Threads can write to both Objects ! Which copy is correct ? Thread B Thread A 􀇾 Concurrent copying FROM Space TO Space References CONCURReNCY IS HARD... FORWARDING
105. FORWARDING x = 1 y = 2 Z = 3 References HEADERS Solution could be installing a Brooks Pointer... Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
106. FORWARDING x = 1 y = 2 Z = 3 References HEADERS ...which points to object header itself Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
107. Copy the Object References FORWARDING x = 1 y = 2 Z = 3 HEADERS FORWARDING x = 1 y = 2 Z = 3 HEADERS Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
108. Install forwarding pointer to itself References FORWARDING x = 1 y = 2 Z = 3 HEADERS FORWARDING x = 1 y = 2 Z = 3 HEADERS Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
109. Nobody knows about copy References FORWARDING x = 1 y = 2 Z = 3 HEADERS FORWARDING x = 1 y = 2 Z = 3 HEADERS Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
110. Atomically update forwarding pointer of original object to new copy References FORWARDING x = 1 y = 2 Z = 3 HEADERS FORWARDING x = 1 y = 2 Z = 3 HEADERS Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
111. FORWARDING x = 4 y = 5 Z = 3 HEADERS FORWARDING x = 1 y = 2 Z = 3 HEADERS Threads now will always fi nd the right object Thread B Thread A References Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
112. FORWARDING x = 4 y = 5 Z = 3 HEADERS FORWARDING x = 1 y = 2 Z = 3 HEADERS When all references are updated... References Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
113. FORWARDING x = 4 y = 5 Z = 3 HEADERS Remove the old object References Concurrent copying FROM Space TO Space CONCURReNCY IS HARD...
114. COllectOrs in the JVM
115. SErial Serial
116. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD SERIaL Single core systems with small heap (<4GB) No pause time requirements ALL JDK'S NO NO YES SMALL - MEDIUM LONGER LOW HIGHER LOW (1-5%) JVM SWITCH > java -XX:+UseSerialGC CHOOSE WHEN BEST SUITED FOR Single threaded applications Development environments Microservices on small nodes Serial OS SUPPORT
117. Automatically selected if only a single processor is available Automatically selected if the avail. memory less than 1792 MB Mark and Compact SERIaL NOTES Serial Application Threads Application Threads GC Thread Application Threads Application Threads GC Thread Young Generation Old Generation
118. Parallel parallEl
119. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD parallEl Multi-core systems with small heap (<4GB) Peak performance is needed without pause time requirements ALL JDK'S YES NO YES MEDIUM - LARGE MODERATE HIGH LOWER MODERATE (5-10%) JVM SWITCH > java -XX:+UseParallelGC CHOOSE WHEN BEST SUITED FOR Batch processing Scienti fi c computing Data analysis Parallel OS SUPPORT
120. Default garbage collector from JDK 5 to JDK 8 Mark and Compact parallEl NOTES Parallel Application Threads Application Threads GC Threads Application Threads Application Threads GC Thread Young Generation Old Generation
121. CMS CMS DEPRECATED Concurrent Mark and Sweep
122. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD CMS Response time is more important than throughput Pause time must be kept shorter than 1 sec JDK 1.4 - 13 YES PARTIALLY YES MEDIUM - LARGE MODERATE MODERATE MODERATE MODERATE (5-15%) JVM SWITCH > java -XX:+UseConcMarkSweepGC CHOOSE WHEN BEST SUITED FOR Web applications Mediums sized enterprise systems CMS OS SUPPORT
123. Deprecated as of JDK 9 Removed from JDK 14 Concurrent marking but no compaction -> Fragmentation CMS NOTES CMS Application Threads STW Initial Marking Application + Concurrent Marking STW Remarking Application + Concurrent Sweeping
124. G1 G1 Garbage First
125. G1 Heap-Layout G1 Max no. of region <= 2048 8 GB Heap = 8192 MB 8192 MB / 2048 = 4 MB region size Heap Region < 4 GB - 1 MB < 8 GB - 2 MB < 16 GB - 4 MB < 32 GB - 8 MB < 64 GB - 16 MB > 64 GB - 32 MB Example 8GB Heap: Region size 1 - 32 MB Unassigned region
126. G1 Heap-Layout G1 Max no. of region <= 2048 8 GB Heap = 8192 MB 8192 MB / 2048 = 4 MB region size Heap Region < 4 GB - 1 MB < 8 GB - 2 MB < 16 GB - 4 MB < 32 GB - 8 MB < 64 GB - 16 MB > 64 GB - 32 MB Eden region Survivor region Tenured region Unassigned region Example 8GB Heap: Region size 1 - 32 MB Young Gen 5 - 60% Humongous region (> 0.5 * Region size) Old Gen
127. G1 Heap-Layout G1 Max no. of region <= 2048 8 GB Heap = 8192 MB 8192 MB / 2048 = 4 MB region size Heap Region < 4 GB - 1 MB < 8 GB - 2 MB < 16 GB - 4 MB < 32 GB - 8 MB < 64 GB - 16 MB > 64 GB - 32 MB Example 8GB Heap: Region size 1 - 32 MB Example: 6 Eden Regions 3 Survivor Regions 2 Regions with most garbage will be collected/promoted Eden region Survivor region Tenured region Unassigned region Young Gen 5 - 60% Humongous region (> 0.5 * Region size) Old Gen
128. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD G1 Response time is more important than throughput Pause time should be around 200 ms Heap size is not larger than 16-32 GB JDK 7U4+ YES PARTIALLY YES MEDIUM - LARGE SHORT - MEDIUM HIGH LOWER MODERATE (5-15%) JVM SWITCH > java -XX:+UseG1GC CHOOSE WHEN BEST SUITED FOR Mixed workloads Large sized enterprise systems Responsive in medium to large heaps G1 OS SUPPORT
129. Default collector from JDK 9 onwards Concurrent marking G1 NOTES G1 Application Threads STW Young Gen. + Initial Marking Application + Conc. Root Scanning STW Remarking Application + Conc. Mark STW Copy Partly STW Cleanup
130. Epsilon EpsilOn
131. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD Epsilon EPSILON JDK 11+ - - - - - VERY HIGH VERY LOW VERY LOW JVM SWITCH > java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC CHOOSE WHEN BEST SUITED FOR Testing performance or memory pressure Highest performance is needed and nearly no garbage is created Extremely short lived jobs Last drop latency improvements Last drop throughput improvements OS SUPPORT
132. Shenandoah ShEnandOah
133. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD shEnandOah Response time is a high priority Using a very large heap (100GB+) Predictable response times needed JDK 11.0.9+ YES FULLY NO MEDIUM - LARGE SHORT VERY HIGH VERY LOW MODERATE (10-20%) JVM SWITCH > java -XX:+UseShenandoahGC CHOOSE WHEN BEST SUITED FOR Latency sensitive applications Large scale systems Highly concurrent applications Shenandoah OS SUPPORT
134. Not available in Oracle JDK A bit reduced throughput due to concurrent GC Makes use of new barrier concept, load reference barrier Generational version will come in JDK 24 shEnandOah NOTES Shenandoah
135. ZGC ZGC Z Garbage Collector
136. ZGC ZGC Heap-Layout O Y Y O Y O O Y O O Y Y O O Y O Y O O O O Y Y Y O O O O y Y O HEAP EMPTY REGION YOUNG GEN REGION OLD GEN REGION
137. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD ZGC Response time is a high priority Using a very large heap (100GB+) Predictable response times needed JDK 15 / 21+ YES FULLY NO / YES LARGE SHORT VERY HIGH VERY LOW MODERATE (10-20%) JVM SWITCH > java -XX:+UseZGC -XX:+ZGenerational* CHOOSE WHEN BEST SUITED FOR Low latency sensitive applications Large scale systems Highly concurrent applications ZGC OS SUPPORT * Not needed in the future, because generational ZGC will become the default
138. Non-generational version will be deprecated ZGC NOTES ZGC
139. C4 C4 Concurrent Continues Compacting Collector
140. Part of Azul Zing JVM Makes use of Loaded Value Barrier (LVB) everywhere (Test + Jump which only takes 1 cpu cycle -> very fast) LVB is read and write barrier (guaranteed to be hit on every access) Best performance by using Transparent Huge Pages (Normal page size 4kB, THP size 2MB) C4 NOTES C4
141. C4 C4 MArking PhAse
142. Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M M LVB LVB LVB M
143. M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M M LVB LVB LVB M
144. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M M M LVB LVB LVB M
145. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M M M LVB LVB LVB M
146. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M App. Thread M M LVB LVB LVB M
147. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M Trigger LVB App. Thread M LVB LVB LVB M
148. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M Test+Jump App. Thread M LVB LVB LVB M
149. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M Mark App. Thread M M LVB LVB LVB M
150. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M Hand over to GC App. Thread M M LVB LVB LVB M
151. M M M Root Marking Phase C4 C4 LVB LVB LVB LVB LVB GC Threads M No need to mark again by GC ! App. Thread M M LVB LVB LVB M
152. C4 C4 quick releAse
153. C4 Relocation Phase C4 Virtual Memory A B C D E Virtual Region Physical
154. C4 C4 Virtual Memory A B C D E A' Virtual A > A' Off-Heap Page Move the object Relocation Phase (Compaction) Store mapping in off-heap page (no forwarding pointer) Physical Physical
155. C4 C4 Virtual Memory A B C D E A' B' Virtual A > A' B > B' Off-Heap Page Relocation Phase (Compaction) Physical Physical No mapping information in the object header -> direct release of physical memory
156. C4 C4 Virtual Memory A B C D E A' B' Virtual A > A' B > B' Off-Heap Page Relocation Phase (Compaction) Physical Physical No mapping information in the object header -> direct release of physical memory
157. C4 C4 Virtual Memory A B C D E A' B' C' Virtual A > A' B > B' C > C' Off-Heap Page Relocation Phase (Compaction) Physical Physical
158. C4 C4 Virtual Memory A B C D E A' B' C' D' Virtual A > A' B > B' C > C' D > D' Off-Heap Page Relocation Phase (Compaction) Physical Physical
159. C4 C4 Virtual Memory A B C D E A' B' C' D' Virtual E' A > A' B > B' C > C' D > D' E > E' Off-Heap Page Relocation Phase (Compaction) Physical Physical
160. C4 C4 Virtual Physical Memory A B C D E A' B' C' D' Virtual Physical E' A > A' B > B' C > C' D > D' E > E' Off-Heap Page Relocation Phase (Quick Release) App thread tries to access old location following the old reference and hits the LVB App. Thread LVB
161. C4 C4 Virtual Physical Memory A B C D E A' B' C' D' Virtual Physical E' A > A' B > B' C > C' D > D' E > E' Off-Heap Page Relocation Phase (Quick Release) Gets new location from Off-Heap forwarding page App. Thread
162. C4 C4 Virtual Physical Memory A B C D E A' B' C' D' Virtual Physical E' A > A' B > B' C > C' D > D' E > E' Off-Heap Page Relocation Phase (Quick Release) Updates the reference and can access object at new location App. Thread
163. AVAILABILITY PARALLEL CONCURRENT GENERATIONAL HEAP SIZE PAUSE TIMES THROUGHPUT LATENCY CPU OVERHEAD C4 Response time is a high priority Using a very large heap (100GB+) Predictable response times needed AZUL ZING JVM YES FULLY YES LARGE SHORT VERY HIGH VERY LOW MODERATE (10-20%) JVM SWITCH > - CHOOSE WHEN BEST SUITED FOR Low latency sensitive applications Large scale systems Highly concurrent applications C4 OS SUPPORT
164. Only available in Azul Zing JVM No performance overhead because of faster Falcon compiler C4 NOTES C4 Mark Relocate Remap Mark Relocate Remap Mark Relocate Remap App Thread App Thread GC Thread GC Thread
165. Which One...?
166. Which One...? Essential Criteria Throughput Percentage of total time spent in application vs. memory allocation and garbage collection
167. Which One...? Essential Criteria Throughput Percentage of total time spent in application vs. memory allocation and garbage collection Latency Application responsiveness, affected by gc pauses
168. Which One...? Essential Criteria Throughput Percentage of total time spent in application vs. memory allocation and garbage collection Latency Application responsiveness, affected by gc pauses Resource usage The working set of a process, measured in pages and cache lines
169. Which One...? Essential Criteria 2 out of 3 Very Low Latency Very high throughput Low resource usage
170. which One...? Choose dependent on your workload C4*, ZGC, Shenandoah G1, CMS Parallel, Serial 1 ms 10 ms 100 ms 1 s 10 s Pause times Runtime overhead 20% 15 % 10 % 5% 0% * C4 has less overhead due to faster Falcon compiler
171. Overview
172. Serial Parallel CMS G1 Epsilon Shenandoah ZGC C4 Serial GC Parallel GC CMS GC G1 Epsilon Shenandoah ZGC C4 Availability ALL JDK's ALL JDK's JDK 1.4-13 JDK 7u4+ JDK 11+ JDK 11.0.9+ JDK15 / 21+ Azul Zing 8+ Parallel NO YES YES YES YES YES YES Concurrent NO NO PARTIALLY PARTIALLY FULLY FULLY FULLY Generational YES YES YES YES NO NO / YES YES Heap Size SMALL - MEDIUM MEDIUM - LARGE MEDIUM - LARGE MEDIUM - LARGE LARGE VERY LARGE VERY LARGE Pause Times LONGER MODERATE MODERATE SHORT - MEDIUM VERY SHORT (<10ms) VERY SHORT (<1ms) VERY SHORT (<1ms) Throughput LOW VERY HIGH MODERATE HIGH VERY HIGH VERY HIGH VERY HIGH VERY HIGH Latency HIGHER LOWER MODERATE LOWER VERY LOW VERY LOW VERY LOW Performance LOWER HIGHER MODERATE HIGHER VERY HIGH VERY HIGH VERY HIGH VERY HIGH CPU Overhead LOW LOWER MODERATE MODERATE VERY LOW LOW - MODERATE MODERATE - HIGH MODERATE - HIGH Tail latency HIGH HIGH HIGH HIGH MODERATE LOW LOW Overview
173. TOOLING...
174. TOOLING JITWatch A tool for understanding the JVM JIT (https://github.com/AdoptOpenJDK/jitwatch/wiki) jHiccup A non intrusive tool to monitor platform "hiccups" incl. JVM stalls (https://github.com/giltene/jHiccup) VisualVM All in one Java troubleshooting tool (https://visualvm.github.io/) GCeasy Universal GC Log Analyzer (https://gceasy.io) JPro fi ler All in one Java pro fi ler (https://www.ej-technologies.com/jpro fi ler) YourKit Java Pro fi ler CPU and Java pro fi ler (https://www.yourkit.com/features/) $
175. w AnnA knOw mOre ?
176. W ANNA KNOW MORE ? R. Jones et al. “The Garbage Collection Handbook”. Chapman & Hall/CRC, 2012
177. thank yOu G1 Epsilon CMS Parallel ZGC Serial Shenandoah C4 Epsilon