Have you ever seen an OutOfMemoryError? I'm sure you have. But then, did you understood that line you copied from StackOverflow? If you haven't, and if you want a gently introduction to the complex world of Java Garbage Collection this is your talk. I'll talk about garbage collection concepts, the garbage collection in the Hotspot JVM (the default in Oraclel's JDK/JRE) and I'll try to put it in terms that any Java developer can grasp. The next time you'll face the dreaded 'OutOfMemoryError', at least, you'll know what are you up against.

1. Garbage Collectors
Alonso Torres @alotor

2. Someone
“I know”
(definitely not me)

4. java.lang.OutOfMemoryError: unable to create new native thread
java.lang.OutOfMemoryError: Stack overflow
java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: Metaspace
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: requested... Out of swap space?

7. DONE!!

8. Java needs lots of memory!!!
Java is so slow!!!!!!
Garbage collection is
wrong!!!!!

9. With CMS GC, the full collection is serial and STW,
hence your application threads are stopped for the
entire duration while the heap space is reclaimed
and then compacted.
The duration for the STW pause depends on your
heap size and the surviving objects.
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All

10. With CMS GC, the full collection is serial and STW,
hence your application threads are stopped for the
entire duration while the heap space is reclaimed
and then compacted.
The duration for the STW pause depends on your
heap size and the surviving objects.
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All

12. Garbage Collectors
WTF?!
Why They Fail?!

13. Alonso Torres
@alotor

14. 1. Structure of JVM’s memory
2. Concepts about Garbage Collection
3. Types of collectors in Oracle’s Hotspot
4. Configurations inside JVM about GC

15. Introducing
JVM

16. JVM PROCESS

17. JVM PROCESS

18. JVM PROCESS

19. Stack
- Execution memory
- Per-thread
- Stack limit (call depth before stack overflow)
● Java 7 ~ 10,000
● Java 8 ~ 20,000

21. JVM PROCESS

22. Permgen vs Metaspace
- Store information about classes
- Java <= 7 Permgen is part of the heap
- Java >= 8 Metaspace is native memory

23. JVM PROCESS

24. HEAP
- Reserved block of memory that the JVM will be in
charge of managing
- Stores object’s data
- Dynamic memory

25. JVM PROCESS

26. FREEUSED
Max. Heap Size

27. FREEUSED
Max. Heap Size

28. FREEUSED
Max. Heap Size

29. FREEUSED
Max. Heap Size

30. LIBREUSED
Max. Heap Size

31. GROW the heap
or
FREE memory

32. USED FREE
USED FREE
Grow the heap
Free the heap

33. How do we free the memory that
we don’t need anymore?

34. 1. Searches for objects that are alive
2. Frees memory used by dead objects
3. Reallocates memory for alive objects
Garbage Collection

35. - Serial Collector
- Parallel Collector
- CMS Collector
- G1
GC’s en OpenJDK Hotspot

36. - Serial Collector
- Parallel Collector
- CMS Collector
- G1
GC’s en OpenJDK Hotspot

37. DAMN YOU
CONCEPTS!!

38. - Most objects die young
- Old objects, normally, don’t reference younger
ones
Weak Generational Hypothesis

39. Two kind of collection:
○ 1 small space with lots of deads
○ 1 big space mostly objects alive
Generational GC

40. DeathRate
Age

41. DeathRate
Age

42. Every JVM
Garbage Collector
is generational

43. YOUNG OLD/TENURE
Generational heap structure

44. S
U
R
V
I
V
O
R
S
OLD/TENUREEDEN
Generational heap structure
S
U
R
V
I
V
O
R
S

49. Collect the young generation

50. Collect the young generation
Promoted objects go to the survivors space and to
the old generation

55. The old generation is full
We need a full collection

56. Empty young and survivors.
Free dead old-gen objects

57. Only currently alive objects

58. Characteristics of GC
Concurrent
Parallel
Incremental
STW
Serial
Monolithic

59. - Global stop of every thread to execute a
garbage collection
- The opposite would be CONCURRENT
○ GC executed at the same time as the
program
Stop the World (STW)

60. STW Concurrent

61. ● GC executed in several threads
● Will leverage multi-core processors
● The opposite would be SERIAL
○ Only one thread for the GC
Parallel

62. Parallel Serial

63. ● Collection in several phases or steps
● Steps/phases can be of different types
● Opposite is: MONOLITHIC
○ Everything in one go
Incremental

64. Incremental Monolithic

65. Characteristics of GC
Concurrent
Parallel
Incremental
STW
Serial
Monolithic

66. Parallel Concurrent

67. Latency
Maximum time the application is stopped doing GC
Throughput
Percentage of time not dedicated to GC
Latency and throughput

68. 15
seconds
5
seconds
30
seconds
Throughput: 90%
15 + 5 + 30 = 100%
15 + 30 = T
T = (50 / 45) * 100
= 90%
Latency: 5 seconds

69. ● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s in OpenJDK Hotspot

70. YOUNG GENERATION OLD GENERATION
Serial
Monolithic
STW
Copying Mark / Sweep / Compact
Serial Collector

72. - Copies the alive objects from one memory
region to another
- Frees the source memory zone (moves)
Copying algorithm (Scavenge)

74. 1. Mark
Mark / Sweep / Compact (MSC)

75. 2. Sweep
Mark / Sweep / Compact (MSC)

76. 3. Compact
Mark / Sweep / Compact (MSC)

77. ● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s en OpenJDK Hotspot

78. Parallel Collector
YOUNG GENERATION OLD GENERATION
Parallel Serial / Parallel
Monolithic
STW
Copying Mark / Sweep / Compact

80. Parallel collector
maximize throughput

81. ● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s en OpenJDK Hotspot

82. YOUNG GENERATION OLD GENERATION
Parallel Serial + Parallel
Monolithic Incremental
STW STW + Concurrent
Copying Mark and Sweep
Concurrent Mark & Sweep

83. 1. Initial Mark
2. Concurrent Mark
3. Remark
4. Concurrent Sweep
Concurrent Mark & Sweep

84. CMS
minimize latency pause

86. but
does NOT compact

87. CMS after several collections

88. STW, Serial, Monolithic, MSC*
*AKA: Full GC
When there is excessive
fragmentation

89. ● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s en OpenJDK Hotspot

90. - Delay as much as possible a “Full GC”
- Low latency
- Predictability
- Easy to use
Garbage First (G1)

91. - Divides the heap in regions
- 2048 regions. Size: heap / 2048 ~ nearest factor of 2
- Frees first the regions with more garbage
(Garbage First)
- Compacts while moving
Garbage First (G1)

92. G1 Heap Structure

93. E O
O
E
O
O
O
S
G1 Heap Structure
E

94. 1. Collects the Young Generation
2. Concurrent marking
3. Mixed collection
4. Evacuation failure
Garbage First (G1)

95. E O
O
E
O
O
O
E
Young collection
E

96. Young collection
E O
O
E E
O
O
O
E

97. Young collection
O
O
O
O
O
S

98. 1. Collects the Young Generation
2. Concurrent marking
3. Mixed collection
4. Evacuation failure
Garbage First (G1)

99. Concurrent marking
E O
O
O
O
O
E
O
O O
E S

100. Concurrent marking
E O
O
E
X
O
X
O
O O
O

101. 1. Collects the Young Generation
2. Concurrent marking
3. Mixed collection
4. Evacuation failure
Garbage First (G1)

102. Mixed collection
E O
O
E
E X
O
X
E
O
O O
O
O
O
O
O

103. Mixed collection
E O
O
E
E X
O
X
E
O
O O
O
O
O
O
O

104. Mixed collection
O
O
O
X
O
O O
O
O
O
O
OS

105. 1. Collects the Young Generation
2. Concurrent marking
3. Mixed collection
4. Evacuation failure
Garbage First (G1)

106. Evacuation failure
O
O
O
O
O O
O
O
O
O
S O
O
O
O
O
O
O O
O
OO O
O
O
O
O
O
O
O
O
OO
E
E
E
Not enough space for collect the young or
survivors. What happens then?

107. Full GC
STW, Serial, Monolithic, MSC

109. All the GCs in Oracle’s JVM
eventually Stop The World

110. Special treatment for “huge” objects
- Objects > 50% region size
- Special Humongous region
- Not moved between regions: More fagmentation!
- If using G1 try to avoid huge objects
G1 - Humongous objects

111. Humongous collection
H
O
O
X
O
O O
O
O
O
O
OS

112. - Region Size = Heap Size / 2048
- Humongous Threshold = Region Size / 2
If your Heap is very small, every object can
become humongous!
G1 - Humongous objects

113. CMS vs G1

114. CMS vs G1
Minimize duration of STW Minimize quantity of STW
Throughput Latency
Old New-ish
Better for small heaps The best for large heaps
Fragmentation Compacts

115. CMS vs G1
Bottom line:
- G1 is the new default GC for Java 9
- Long term replacement for the CMS
If you want throughput Parallel GC it’s better

116. JVM configuration

118. Maximum Heap Size
- Big heap long STW pauses
- Small heap lots of small pauses

119. -Xms512m -Xmx8g
Max. Heap SizeInitial Heap Size

120. Choose your poison

121. Serial
Parallel
CMS
G1
-XX:+UseSerialGC
-XX:+UseParallelGC
-XX:+UseConcMarkSweepGC
-XX:+UseG1GC

122. java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=191892544
-XX:MaxHeapSize=3070280704
-XX:+PrintCommandLineFlags
-XX:+UseCompressedClassPointers
-XX:+UseCompressedOops
-XX:+UseParallelGC

123. docker run -it java:9 java -XX:+PrintCommandLineFlags -version
-XX:G1ConcRefinementThreads=4
-XX:InitialHeapSize=191892544
-XX:MaxHeapSize=3070280704
-XX:+PrintCommandLineFlags
-XX:ReservedCodeCacheSize=251658240
-XX:+SegmentedCodeCache
-XX:+UseCompressedClassPointers
-XX:+UseCompressedOops
-XX:+UseG1GC

124. 1. Never do premature optimization
2. Maximize young collection
3. Minimize STW
4. Avoid large objects
5. Minimize object retention
Optimization targets

125. and gather data

126. -Xloggc:<file>
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
GC Logs

127. [GC [PSYoungGen: 578424K->8793K(630784K)]
1007570K->444386K(1155072K), 0.0185270 secs]
[Times: user=0.06 sys=0.00, real=0.02 secs]
[GC [PSYoungGen: 580697K->15128K(636928K)]
1016290K->459169K(1161216K), 0.0236090 secs]
[Times: user=0.08 sys=0.01, real=0.02 secs]
[GC [PSYoungGen: 450179K->6893K(635904K)]
894221K->465458K(1160192K), 0.0249430 secs]
[Times: user=0.07 sys=0.02, real=0.02 secs]
[Full GC [PSYoungGen: 6893K->0K(635904K)]
[ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K)
[PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs]
[Times: user=8.48 sys=0.01, real=2.53 secs]

128. [GC [PSYoungGen: 578424K->8793K(630784K)]
1007570K->444386K(1155072K), 0.0185270 secs]
[Times: user=0.06 sys=0.00, real=0.02 secs]
[GC [PSYoungGen: 580697K->15128K(636928K)]
1016290K->459169K(1161216K), 0.0236090 secs]
[Times: user=0.08 sys=0.01, real=0.02 secs]
[GC [PSYoungGen: 450179K->6893K(635904K)]
894221K->465458K(1160192K), 0.0249430 secs]
[Times: user=0.07 sys=0.02, real=0.02 secs]
[Full GC [PSYoungGen: 6893K->0K(635904K)]
[ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K)
[PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs]
[Times: user=8.48 sys=0.01, real=2.53 secs]
Young Generation collection
Full GC (STW)

129. JConsole

131. YOUNG SURVIVORS OLD
Summary of the GC

132. JVisualVM
+
Visual GC plugin

136. JHiccup
https://github.com/giltene/jHiccup

138. Heuristic options

139. -XX:MaxGCPauseMillis=1000
-XX:GCTimeRatio=20
Limit the longest STW. Tries to maintain it on average

140. -XX:MaxGCPauseMillis=1000
-XX:GCTimeRatio=20
Application x20 more time than the GC

141. -XX:MaxGCPauseMillis=LATENCY
-XX:GCTimeRatio=T / (100 - T)

142. Change the generations

143. -XX:NewRatio=3
-XX:SurvivorRatio=8
-XX:MaxNewSize=1G
-XX:MaxTenuringThreshold=15
Ratio between the old and young generation is 1:3

144. -XX:NewRatio=3
-XX:SurvivorRatio=8
-XX:MaxNewSize=1G
-XX:MaxTenuringThreshold=15
Ratio between the eden and survivors 1:8

145. -XX:NewRatio=3
-XX:SurvivorRatio=8
-XX:MaxNewSize=1G
-XX:MaxTenuringThreshold=15
Absolute sizing of the young generation (eden + survivors)

146. -XX:NewRatio=3
-XX:SurvivorRatio=8
-XX:MaxNewSize=1G
-XX:MaxTenuringThreshold=15
Cycles that could live in the “survivors” space

147. G1 options

148. -XX:G1HeapRegionSize=n
-XX:G1NewSizePercent=5
-XX:G1MaxNewSizePercent=60
-XX:ParallelGCThreads=n
-XX:InitiatingHeapOccupancyPercent=45
Size of the regions

149. -XX:G1HeapRegionSize=n
-XX:G1NewSizePercent=5
-XX:G1MaxNewSizePercent=60
-XX:ParallelGCThreads=n
-XX:InitiatingHeapOccupancyPercent=45
Percentage of the regions dedicated to young generation (min/max)

150. -XX:G1HeapRegionSize=n
-XX:G1NewSizePercent=5
-XX:G1MaxNewSizePercent=60
-XX:ParallelGCThreads=n
-XX:InitiatingHeapOccupancyPercent=45
Number of threads for the collection

151. -XX:G1HeapRegionSize=n
-XX:G1NewSizePercent=5
-XX:G1MaxNewSizePercent=60
-XX:ParallelGCThreads=n
-XX:InitiatingHeapOccupancyPercent=45
Occupancy before starts a marking cycle

152. And many more….
http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html

153. java -XX:+PrintFlagsFinal -version | grep "G1.*s"
double G1ConcMarkStepDurationMillis = 10.000000 {product}
uintx G1ConcRSHotCardLimit = 4 {product}
uintx G1ConcRSLogCacheSize = 10 {product}
intx G1ConcRefinementGreenZone = 0 {product}
intx G1ConcRefinementRedZone = 0 {product}
intx G1ConcRefinementServiceIntervalMillis = 300 {product}
uintx G1ConcRefinementThreads = 0 {product}
intx G1ConcRefinementThresholdStep = 0 {product}
intx G1ConcRefinementYellowZone = 0 {product}
uintx G1ConfidencePercent = 50 {product}
uintx G1HeapRegionSize = 0 {product}
uintx G1HeapWastePercent = 5 {product}
uintx G1MixedGCCountTarget = 8 {product}
intx G1RSetRegionEntries = 0 {product}
uintx G1RSetScanBlockSize = 64 {product}
intx G1RSetSparseRegionEntries = 0 {product}
intx G1RSetUpdatingPauseTimePercent = 10 {product}
intx G1RefProcDrainInterval = 10 {product}
uintx G1ReservePercent = 10 {product}
uintx G1SATBBufferEnqueueingThresholdPercent = 60 {product}
intx G1SATBBufferSize = 1024 {product}
intx G1UpdateBufferSize = 256 {product}
bool G1UseAdaptiveConcRefinement = true {product}
bool UseG1GC = false {product}

155. 1. Structure of JVM’s memory
2. Concepts about Garbage Collection
3. Types of collectors in Oracle’s Hotspot
4. Configurations inside JVM about GC

156. With CMS GC, the full collection is serial and STW,
hence your application threads are stopped for the
entire duration while the heap space is reclaimed
and then compacted.
The duration for the STW pause depends on your
heap size and the surviving objects.
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All

157. Don't be afraid of the
big bad wolf

158. Alonso Torres
@alotor @alotor

159. REFERENCES
+ https://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
+ http://blog.takipi.com/garbage-collectors-serial-vs-parallel-vs-cms-vs-the-g1-and-whats-new-in-java-8/
+ http://blog.takipi.com/7-things-you-thought-you-knew-about-garbage-collection-and-are-totally-wrong/
+ http://blog.takipi.com/7-things-you-thought-you-knew-about-garbage-collection-and-are-totally-wrong/
+ http://blog.takipi.com/5-tips-for-reducing-your-java-garbage-collection-overhead/
+ https://adtmag.com/articles/2015/06/22/oracle-java-9.aspx
+ https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html
+ http://blog.mgm-tp.com/2013/12/benchmarking-g1-and-other-java-7-garbage-collectors/
+ http://www.petefreitag.com/articles/gctuning/
+ https://www.infoq.com/author/Monica-Beckwith
+ Java Performance. The Definitive Guide. By Scott Oaks (O'Reilly')
+ Viewer for the CG Logs: https://github.com/chewiebug/GCViewer