The What & The Why of Automatic Memory …• Deep Dive into G1 GC 4 ©2017 CodeKaram Agenda - if time permits… • Allocations • Few Optimizations in OpenJDK HotSpot VM 5 ©2017

The What & The Why of Automatic Memory

Management -with emphasis on OpenJDK HotSpot Virtual Machine

By: Monica Beckwith www.codekaram.com Tweet @mon_beck

©2017 CodeKaram

About Me

• Masters in Electrical and Computer Engineering • Java/JVM/GC performance engineer

• Code Karam LLC • I have worked with Oracle, Sun, AMD …

(https://www.linkedin.com/in/monicabeckwith/) • JVM heuristics, generation of optimized JIT-ted

code, GC performance • I used to work in the capacity of Garbage First

GC performance lead @Oracle.

2

©2017 CodeKaram

Agenda • What is Garbage/Memory Management?

• Quick Overview

• Automatic Memory Management Basic Considerations

• Techniques of Automatic Memory Management

• Further Considerations

3

©2017 CodeKaram

Agenda - continued

• Few Garbage Collection Algorithms in OpenJDK HotSpot VM

• Comparison

• Key Topics

• Deep Dive into G1 GC

4

©2017 CodeKaram

Agenda - if time permits…

• Allocations

• Few Optimizations in OpenJDK HotSpot VM

5

©2017 CodeKaram

Memory Management

6

©2017 CodeKaram

Allocation

+ Reclamation

7

©2017 CodeKaram 8

Manual vs Automatic Deallocation

©2017 CodeKaram 9

Manual Process Root Set

Allocation Space

Root Set

©2017 CodeKaram 10

Space Getting Filled Up Root Set

Allocation Space

©2017 CodeKaram 11

Root Set

Allocation Space

Allocation Space Full

©2017 CodeKaram 12

Root Set

Allocation Space

©2017 CodeKaram 13

Root Set

Allocation Space

Problems!!

©2017 CodeKaram 14

Root Set

Allocation Space

Problems!!

Can lead to memory

leak!!

©2017 CodeKaram 15

Root Set

Allocation Space

Problems!!

©2017 CodeKaram 16

Root Set

Allocation Space

Problems!!

Dangling Pointers!!

©2017 CodeKaram 17

What Can We Do?

©2017 CodeKaram

Stack Based Allocation

18

Push & Pop Will Take Care of Issues

©2017 CodeKaram

Region Based Allocation

19

Allocation Area at the Beginning gets Deallocated at the End

Presenter

Presentation Notes

stack of regions

©2017 CodeKaram

Automatic Memory Management

20

Presenter

Presentation Notes

stack of regions

©2017 CodeKaram

Collection Efficiency

21

Basic Considerations

It May Be More Efficient To Let Some Garbage Be!

©2017 CodeKaram

Performance Trifecta

22

Basic Considerations

Responsiveness, Footprint and Throughput!

©2017 CodeKaram

If I send a stimulus now, how much time ’til I get a response back?

23

Responsiveness

Presenter

Presentation Notes

So what do I mean by responsiveness? responsiveness to me means the time until I get a response back from the stimulus that I have sent to the system. This stimulus to many people could mean the start of a transaction or a database access request or an update request or a read request by the processor.

©2017 CodeKaram

Can I fit in more? OR

How can I optimize out redundancy?

24

FootPrint

Presenter

Presentation Notes

What about footprint? As a performance person, I can define footprint in two ways - first, can I fit in more (data, objects, etc) in the space available and secondly, can i optimize out redundant information and maybe compact to save space.

©2017 CodeKaram

How can I maximize the operations per second of my system?

25

Throughput

Presenter

Presentation Notes

Finally, the third aspect is throughput. How much can I push through? Basically I want to maximize the operations that I can perform per second on my designed system.

©2017 CodeKaram

Techniques of Automatic Memory

Management

26

©2017 CodeKaram 27

Reference Counting vs Tracing Collecto

©2017 CodeKaram 28

Reference Counting

Lower overall

footprint

Non-moving needs to handle

cyclic references

©2017 CodeKaram 29

Tracing

usually has higher

footprint no need of

reserving space for count

great for (co-)locality

©2017 CodeKaram

- The Continuous Tracker

30

Reference Counting

©2017 CodeKaram 31

Root Set

Allocation Space

1 1

1 1 2 1

1

©2017 CodeKaram 32

Root Set

Allocation Space

1 1

1 1 2 1

1

X X

©2017 CodeKaram 33

Root Set

Allocation Space

1 0

1 1 2 0

1

©2017 CodeKaram 34

Root Set

Allocation Space

1 0

1 1 2 0

1

©2017 CodeKaram 35

Root Set

Allocation Space

1

1 1 2

0

©2017 CodeKaram 36

Root Set

Allocation Space

1

1 1 2

0

©2017 CodeKaram 37

Root Set

Allocation Space

1

1 1 2

©2017 CodeKaram 38

Root Set

Allocation Space

1

1 1 2

©2017 CodeKaram

Tracing Collector

39

- Active When Full or When Threshold Crossed

©2017 CodeKaram 40

Root Set

Allocation Space

Allocation Space Full

©2017 CodeKaram

Mark-Sweep Mark-(Sweep-)Compact

Copy Scavenge

41

Different Algorithms

©2017 CodeKaram 42

Root Set

Allocation Space

Marking Phase

©2017 CodeKaram 43

Root Set

Allocation Space

©2017 CodeKaram 44

Root Set

Allocation Space

Sweeping Phase

Free List

©2017 CodeKaram 45

Root Set

Allocation Space Free List

©2017 CodeKaram 46

Root Set

Allocation Space Free List

©2017 CodeKaram 47

Root Set

Allocation Space

Compacting Phase

©2017 CodeKaram 48

Root Set

Allocation Space

©2017 CodeKaram 49

Root Set

Allocation Space

©2017 CodeKaram 50

Root Set

Allocation Space

©2017 CodeKaram 51

Root Set

Allocation Space

©2017 CodeKaram 52

Root Set

From Space To Space

Copying Collector

©2017 CodeKaram 53

Root Set

To Space From Space

©2017 CodeKaram 54

Root Set

To Space From Space

©2017 CodeKaram 55

Root Set

To Space From Space

©2017 CodeKaram 56

Root Set

Allocation Space

©2017 CodeKaram 57

Root Set

From Space To Space

©2017 CodeKaram

Further Considerations

58

Generational Hypothesis

- Most Objects Die Young!

©2017 CodeKaram

Further Considerations

59

Age Threshold

- Promote Only The Long Lived Objects

©2017 CodeKaram

Generational Heap

60

Eden

Young Generation

Old Generation

Survivor Spaces

©2017 CodeKaram

Scavenging

61

Survivor Spaces

Eden

Young Generation

Old Generation

©2017 CodeKaram 62

Survivor Spaces

Eden

Young Generation

Old Generation

©2017 CodeKaram 63

Survivor Spaces

Eden

Young Generation

Old Generation

©2017 CodeKaram 64

… after a while…

©2017 CodeKaram 65

Survivor Spaces

Eden

Young Generation

Old Generation

©2017 CodeKaram 66

Survivor Spaces

Eden

Young Generation

Old Generation

©2017 CodeKaram 67

Survivor Spaces

Eden

Young Generation

Old Generation

©2017 CodeKaram 68

Survivor Spaces

Eden

Young Generation

Old Generation

©2017 CodeKaram

Few GC Algorithms in OpenJDK HotSpot VM

69

©2017 CodeKaram

• Serial GC

• Parallel GC

• Mostly Concurrent Mark & Sweep GC

• Garbage First GC

70

Generational GCs in OpenJDK HotSpot VM

©2017 CodeKaram

Old Generation Collection aka Full Collection is Triggered When

Generation is Full.

71

Serial/Parallel GC

©2017 CodeKaram

Serial GC

72

Young Generation Collection Algorithm

Old Generation Collection Algorithm

Scavenge Mark-Sweep-Compact

©2017 CodeKaram

Parallel GC

73



Scavenge Mark-Compact Parallel Parallel

©2017 CodeKaram

Serial GC

74

Young GC

Thread

Java Application

Threads

Old GC Thread

Java Application

Threads

Java Application

Threads

74

©2017 CodeKaram

Parallel GC

75

Young GC Threads

Java Application

Threads

Old GC Threads

Java Application

Threads

Java Application

Threads

©2017 CodeKaram

Parallel GC

76

= Parallel Scavenge + Parallel Mark Compact

©2017 CodeKaram

Parallel Scavenge

77

• Copy and Promote into Promotion/Parallel Local Allocation Buffers (PLABs)

• Adaptive Sizing

• Parallel Threads (Use -XX:ParallelGCThreads=<n> to change the default)

Presenter

Presentation Notes

divide root set among GC threads above 8 threads 5/8th is the default. work stealing to balance GC threads

©2017 CodeKaram

Parallel Mark-Compact

78

Old Generation

©2017 CodeKaram


79

Old Generation

©2017 CodeKaram


80

Old Generation

source region

destination region

©2017 CodeKaram


81

Old Generation

source region

destination region

©2017 CodeKaram


82

Old Generation

source region

destination region

source region

©2017 CodeKaram


83

Old Generation

source region

destination region

source region

©2017 CodeKaram


84

Old Generation

©2017 CodeKaram

Old Generation Collection is Triggered When Occupancy

Crosses a Marking Threshold.

85

CMS/G1 GC

©2017 CodeKaram

Both Fall Back To Full Collections When All Else Fails

86

CMS/G1 GC

©2017 CodeKaram

CMS GC

87



New (Copying) Mark-Sweep Parallel

©2017 CodeKaram

CMS GC

88

CMS Initial Mark

Threads

Java Application

Threads

Java Application

Threads

Young GC

Threads

CMS RemarkThreads

Concurrent CMS Threads

Java Application

Threads

Java Application

Threads

Java Application

Threads

Young GC

Threads



©2017 CodeKaram

Comparison

89

©2017 CodeKaram 90

*Similar GC Algorithms for generational OpenJDK

HotSpot

Different GC Algorithms for OpenJDK Hotspot

Young Generation Old Generation

©2017 CodeKaram 91

Throughput Maximizer

• Multi-generation heap

• Multi-threaded workers

• Compacting collector

• Faster reclamation via PLABS (Promotion Local Area Buffers)

Parallel GC

©2017 CodeKaram 92

Latency Sensitive

CMS GC


• Multi-threaded workers*

• More work done concurrently

• Multi-phased marking

©2017 CodeKaram 93



• More work done concurrently

• Multi-phased marking



• Incrementally compacting collector

• Faster reclamation via PLABS


Latency Sensitive

G1 GC

©2017 CodeKaram 94


Latency Sensitive Parallel GC

CMS GC

G1 GC

HotSpot GCs

©2017 CodeKaram

Key Topics

95

ons, Promotion Failures, Concurrent Mode Failures and B

©2017 CodeKaram

What’s a Full Collection?

96

A Failsafe Mechanism Triggered Due to Promotion Failure

©2017 CodeKaram

So, Let’s Look at Promotion Failures…

97

©2017 CodeKaram 98

Parallel GC Old Generation

Free Space

Occupied Space

©2017 CodeKaram 99


To-be Promoted Object 1

©2017 CodeKaram 100


Free Space

Occupied Space






Free Space

Occupied Space






Free Space

Occupied Space

©2017 CodeKaram

Next?

105

Promotion Failure ! !


CMS GC Old Generation

Free Space

Occupied Space

Free List


CMS GC Old Generation



Old Generation

Free Space

Occupied Space

Free List

CMS GC


Old Generation


CMS GC


Old Generation

Free Space

Occupied Space

Free List

CMS GC


Old Generation


X

CMS GC


Old Generation


X

CMS GC


Old Generation


X

CMS GC


Old Generation


X

CMS GC


Old Generation


??

CMS GC


Old Generation


Promotion Failure!!

CMS GC


CMS GC - Concurrent Mode Failures

• Your old generation is getting filled before a concurrent cycle can complete and free up space.

• Fragmentation has crept in.

• Causes - marking threshold is too high, heap too small, or high application mutation rate

©2017 CodeKaram

Basic Tuning

118

Avoid or Delay Full Collections

©2017 CodeKaram

Only promote objects after you have aged them appropriately

119

Tuning Goal

Aim at a GC Overhead of < 5%

©2017 CodeKaram

G1 GC - Pause Histogram

120

0

30

60

90

120

150

3415 3416.3 3417.2 3418.4 3419 3422 3423.4 3432.2 3433.2 3436.8 3437.6 3438.9 3440

Paus

e tim

e in

milli

seco

nds

Timestamps

Young Collection Initial Mark Remark Cleanup Mixed Collection

Occupancy == Initiating Heap Occupancy Percent

Presenter

Presentation Notes

As of OpenJDK 8 update 40, the remark stage is stop-the-world. A final stop-the-world pause is nec- essary to cover all the live data and safely complete live data accounting. In order to reduce time spent in this pause, multiple GC threads are used to parallel process the log buffers. Any application that heavily uses reference objects (weak references, soft references, phantom references, or final references) may see high remark times as a result of the reference-processing overhead. Current heuristics rank the regions according to liveness (the regions that have a lot of live objects are really expensive to collect

©2017 CodeKaram

Size Young Generation Appropriately

121

Tips

Cases, Young Generation Sizing has the Most Effect on Th

©2017 CodeKaram


122

Tips

Overflow Gets Promoted into the Old Generation

©2017 CodeKaram


123

Tips

Transient Data May Need a Larger Survivor Space

©2017 CodeKaram

Pay Attention to the Marking Threshold

124

Tips (Where Applicable)

A Delayed Start to the Marking Phase May Not Be Able to Keep Up With The Promotion Rate

Allocation and Promotion Rates

125

©2017 CodeKaram

Plot Allocation & Promotion Rates

126


Young Occupancy before GC Young Gen Size Old Gen Occupancy after GC

Heap Occupancy before GC Heap Occupancy after GC Heap Size

Timestamps

©2017 CodeKaram

Let’s Talk About G1 GC! :)

128

G1 GC Background

129

Regionalized Heap

130

Presenter

Presentation Notes

Heap region size = heap size/2048; can range from 1 MB to 32 MB; is a power of 2; is aligned

©2017 CodeKaram

Traditional Java Heap

131

Contiguous Java Heap

Eden S0 S1

Old Generation

©2017 CodeKaram

The Generational Java Heap

Eden S0 S1 Old Generation

Young Generation

Allocations Survivors

Tenured

132

Presenter

Presentation Notes

Here we see the young generation and the old generation. We also see eden and S0 and S1 survivor spaces also known as to and from spaces. Most allocations happen in the eden space from the young generation. As the eden starts to fill up there comes a time that no more allocations can happen and we encounter an allocation failure that triggers a young collection. The surviving live objects are then moved to the survivor space S0. There will be multiple of these young collections which will enable the surviving objects to age in either the S0 or the S1 spaces. Finally after the object reaching their aging threshold also known as tenuring threshold they are tenured or promoted into the old generation. Once the old generation gets filled we encounter promotion failure and that triggers a full collection in most traditional GCs. G1 GC is a bit more complicated than that.



Eden S0 S1

Presenter

Presentation Notes

OK. So now we see the generations here.



HotSpot



Presenter

Presentation Notes

The young generation algorithm is similar for generational HotSpot collectors. The old generation algorithm is different for all collectors.



HotSpot



Presenter

Presentation Notes

Let’s talk about generational collectors in HotSpot and the difference between the old generation algorithms and the drivers.

©2017 CodeKaram

Garbage First GC - Heap Regions

136

Contiguous Java Heap

Free Region

Non-Free Region

Presenter

Presentation Notes

Heap region size = heap size/2048; can range from 1 MB to 32 MB; is a power of 2; is aligned

©2017 CodeKaram

G1 GC Heap Regions

• Young Regions - Regions that contain objects in the Eden and Survivor Spaces

• Old Regions - Regions that contain objects in the Old generation.

• Humongous Regions - Regions that contain Humongous Objects.

137

©2017 CodeKaram

Eden

Old Old

Eden

Old

Survivor

Humongous

138

Garbage First GC - Heap Regions

Humongous Objects

139

©2017 CodeKaram

Humongous Objects

140

An old generation region

A young generation region

©2017 CodeKaram

Humongous Objects

141

Object < 50% of G1 region size

Object >= 50% of G1 region size

Object > G1 region size

??


Object < 50% of G1 region size

Humongous Objects


Object >= 50% of G1 region size

Humongous Objects


Object > G1 region size

Humongous Objects


Object NOT Humongous

Object Humongous

Object Humongous -> Needs Contiguous Regions

Humongous Objects

Presenter

Presentation Notes

wasted space is (internal) fragmentation. Say, the current G1 region size is at 2MBs. And say, that the length of a byte array is aligned at 2MB. This byte array will be considered a humongous object and will need to be allocated as such but it will need contiguous regions since the 2MB array length doesn't include the header size.

G1 GC Maintenance

146

Collection Set

147

©2017 CodeKaram

Collection Set

• A young collection set (CSet) will incorporate all the young regions

• A mixed collection set will incorporate all the young regions and a few candidate old regions based on the “most garbage first” principle.

148

©2017 CodeKaram

Eden

Old Old

Eden

Old

Survivor

CSet during a young collection -

149

Collection Set

Presenter

Presentation Notes

During any garbage collection pause all the regions in the CSet are freed. A CSet is a set of regions that are targeted for reclamation during a garbage collection pause. All live objects in these candidate regions will be evacuated during a collection, and the regions will be returned to a list of free regions. During a young collection, the CSet can contain only young regions for collection.

©2017 CodeKaram

Old Old

Old

CSet during a mixed collection -

Survivor

Old

Eden Eden

150

Collection Set

Presenter

Presentation Notes

A mixed collection, on the other hand, will not only add all the young regions but also add some old candidate regions (based on their GC efficiency) to its CSet.

Remembered Sets

151

©2017 CodeKaram

Remembered Sets

• Additional data structures to help with maintenance

• Add a slight footprint overhead (~5%)

152

©2017 CodeKaram

• Maintain and track incoming references into its region

• old-to-young references

• old-to-old references

• Remembered sets have varying granularity based on the “popularity” of objects or regions.

153

Remembered Sets

Presenter

Presentation Notes

With G1 GC, during any young or mixed collection, the young generation is always collected in its entirety, eliminating the need to track references whose containing object resides in the young generation. This reduces the RSet overhead. Thus, G1 GC just needs to maintain the RSets in the following two scenarios: Old-to-young references—G1 GC maintains pointers from regions in the old generation into the young generation region. The young generation region is said to “own” the RSet and hence the region is said to be an RSet “owning” region. � Old-to-old references—Here pointers from different regions in the old generation will be maintained in the RSet of the “owning” old generation region.

G1 GC Phases

155

©2017 CodeKaram

G1 GC - Pause Histogram

156

0

30

60

90

120

150

3415 3416.3 3417.2 3418.4 3419 3422 3423.4 3432.2 3433.2 3436.8 3437.6 3438.9 3440

Paus

e tim

e in

milli

seco

nds

Timestamps

Young Collection Initial Mark Remark Cleanup Mixed Collection

Occupancy == Initiating Heap Occupancy Percent

Presenter

Presentation Notes

As of OpenJDK 8 update 40, the remark stage is stop-the-world. A final stop-the-world pause is nec- essary to cover all the live data and safely complete live data accounting. In order to reduce time spent in this pause, multiple GC threads are used to parallel process the log buffers. Any application that heavily uses reference objects (weak references, soft references, phantom references, or final references) may see high remark times as a result of the reference-processing overhead. Current heuristics rank the regions according to liveness (the regions that have a lot of live objects are really expensive to collect

A Young Collection

157

©2017 CodeKaram

The Garbage First Collector

Eden

Old Old

Eden

Old

Survivor

E.g.: Current heap configuration -

158

©2017 CodeKaram


Eden

Old Old

Eden

Old

Survivor

E.g.: During a young collection -

159

©2017 CodeKaram


Old Old

Old

E.g.: After a young collection -

Survivor

Old

160

©2017 CodeKaram

Old Old

Old Survivor

Old

Eden Eden

Old


161


Presenter

Presentation Notes

During the concurrent marking phase, any garbage-filled regions are reclaimed as a part of the cleanup phase.

Marking Initiation

162

Presenter

Presentation Notes

A mixed collection cycle can happen only after the marking/IHOP threshold is crossed and after the completion of a concurrent marking cycle.

©2017 CodeKaram

Initiating Heap Occupancy Percent

163

• Threshold to start the concurrent marking cycle to identify candidate old regions.

• When old generation occupancy crosses this adaptive threshold.

• Based on the total heap size.

Presenter

Presentation Notes

In order to identify old regions with the most garbage, G1 GC initiates a concurrent marking cycle, which helps with marking roots and eventually identifying all live objects and also calculating the liveness factor per region. There needs to be a delicate balance between the rate of allocations and promotions and the triggering of this marking cycle such that the JVM process doesn’t run out of Java heap space. Hence, an occupancy threshold is set at the start of the JVM process. As of this writing and up through at least JDK 8u45 this occupancy threshold is not adaptive When the total heap occupancy reaches (or exceeds) the IHOP threshold, a concurrent marking cycle is initiated. Toward the end of marking, G1 GC calculates the amount of live objects per old region. Also, during the cleanup stage, G1 GC ranks the old regions based on their “GC efficiency.” Now a mixed collection can happen! During a mixed collection pause, G1 GC not only collects all of the regions in the young generation but also collects a few candidate old regions such that the old regions with the most garbage are reclaimed.

©2017 CodeKaram

Initiating Heap Occupancy Percent - Helpful Options

164

• -XX:InitiatingHeapOccupancyPercent=<p>

• -XX:ConcGCThreads=<n>

Presenter

Presentation Notes


The Concurrent Marking Stages

165

©2017 CodeKaram

Stages of Concurrent Marking

166

• Initial-mark

• Root region scan

• Concurrent mark

• Remark / Final mark

• Cleanup

Presenter

Presentation Notes


©2017 CodeKaram

Class Unloading with Concurrent Mark

• With JDK 8 update 40, you have ClassUnloadingWithConcurrentMark, and unreachable classes can be unloaded during Remark.

167

©2017 CodeKaram

Old Old

Old

.: Reclamation of a garbage-filled region during the cleanup phas

Survivor

Old

Eden Eden

Old


168

Presenter

Presentation Notes

During the concurrent marking phase, any garbage-filled regions are reclaimed as a part of the cleanup phase.

©2017 CodeKaram

Old Old

Old

.: Reclamation of a garbage-filled region during the cleanup phas

Survivor

Old

Eden Eden


169

Incremental Compaction aka Mixed Collection

170

©2017 CodeKaram

Old Old

Old


Survivor

Old

Eden Eden


171

Presenter

Presentation Notes

For G1 GC, the old generation collection consists of all of the young regions and a few candidate old regions. Such a collection is called a mixed collection. The GC ergonomics selects the candidate old regions based on certain thresholds and calculations that help determine the regions with the most reclaimable space and at the same time giving consideration to the pause time goal.

©2017 CodeKaram

Old Old

Old

E.g.: During a mixed collection -

Survivor

Old

Eden Eden


172

Presenter

Presentation Notes

Based on the total number of candidate old regions, the pause time goal and other collection related thresholds, you could see more that one mixed collection pause. Thus the old generation is collected incrementally.

©2017 CodeKaram

Old

E.g.: After a mixed collection -

Old

Survivor

Old


173

Tuning Considerations with G1 GC

174

Taming Mixed GCs

175

©2017 CodeKaram

Say, The young collections are meeting your SLAs, but…

The mixed collections are far too frequent and too many OR

The mixed collections are blowing your SLAs

176

Why Tame Mixed Collections?


©2017 CodeKaram

If meeting the latency SLA is your only concern: Divide the expensive collection further into smaller inexpensive

collections

178

What Can We Do?

©2017 CodeKaram

Adjusting Each Mixed Collection

179

Minimum number of old regions to be included in the mixed collection set.

Maximum number of old regions to be included in the mixed collection set.

©2017 CodeKaram

Adjusting Each Mixed Collection

180

-XX:G1MixedGCCountTarget=<n>

-XX:G1OldCSetRegionThresholdPercent=<p>

Presenter

Presentation Notes

the 103 region count comes from the total heap size of 1G and the 10 percent default value for G1OldCSetRegionThresholdPercent, which rounds up to 103.

©2017 CodeKaram

If the GC overhead is too high and you have heap to spare (after considering your humongous objects requirements):

Remove the expensive regions from your collection set

181

What Can We Do?

©2017 CodeKaram

Eliminating Expensive Old Regions From Mixed Collections

• You could eliminate based on the liveness per old region

• You could also eliminate expensive old regions towards the end of the sorted array

182

©2017 CodeKaram

Eliminating Expensive Old Regions From Mixed Collections

• -XX:G1MixedGCLiveThresholdPercent = <p>

• -XX:G1HeapWastePercent = <p>

183

Presenter

Presentation Notes

You can specify G1MixedGCLiveThresholdPercent option to set a cut off for expensive regions. Any region with liveness above this threshold will not be included in the CSet of any Mixed collection cycle. Since the old regions are sorted based on their liveness, you can also use the G1HeapWastePercent option to eliminate the most expensive old regions from being included in the CSet of any Mixed collection cycle.

Components of a G1 GC Pause

184


©2017 CodeKaram

Ideally, you will see that most of your pause time is spent in copying live objects…

186

Major Contributor?


©2017 CodeKaram

but, what if that’s not the case?

188

Major Contributor?

189

©2017 CodeKaram

, 0.4066560 secs]

[Parallel Time: 354.9 ms, GC Workers: 48]

[GC Worker Start (ms): Min: 4500060.2, Avg: 4500068.1, Max: 4500085.2, Diff: 24.9]

[Ext Root Scanning (ms): Min: 0.0, Avg: 4.8, Max: 31.8, Diff: 31.8, Sum: 231.0]

[Update RS (ms): Min: 0.0, Avg: 21.6, Max: 116.3, Diff: 116.3, Sum: 1036.3]

[Processed Buffers: Min: 0, Avg: 4.9, Max: 29, Diff: 29, Sum: 234]

[Scan RS (ms): Min: 0.0, Avg: 41.5, Max: 62.3, Diff: 62.2, Sum: 1992.1]

[Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.3]

[Object Copy (ms): Min: 195.6, Avg: 233.1, Max: 261.1, Diff: 65.5, Sum: 11189.0]

[Termination (ms): Min: 21.0, Avg: 45.6, Max: 74.4, Diff: 53.4, Sum: 2188.5]

[GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 4.8]

[GC Worker Total (ms): Min: 329.6, Avg: 346.7, Max: 354.7, Diff: 25.1, Sum: 16642.0]

[GC Worker End (ms): Min: 4500414.7, Avg: 4500414.8, Max: 4500415.0, Diff: 0.2]

190

©2017 CodeKaram

[Code Root Fixup: 0.1 ms]

[Code Root Migration: 0.2 ms]

[Clear CT: 1.4 ms]

[Other: 50.1 ms]

[Choose CSet: 0.0 ms]

[Ref Proc: 34.6 ms]

[Ref Enq: 0.3 ms]

[Free CSet: 7.5 ms]

191

©2017 CodeKaram

[Code Root Fixup: 0.1 ms]

[Code Root Migration: 0.2 ms]

[Clear CT: 1.4 ms]

[Other: 50.1 ms]

[Choose CSet: 0.0 ms]

[Ref Proc: 34.6 ms]

[Ref Enq: 0.3 ms]

[Free CSet: 7.5 ms]

192

©2017 CodeKaram

, 0.4066560 secs]

[Parallel Time: 354.9 ms, GC Workers: 48]

[GC Worker Start (ms): Min: 4500060.2, Avg: 4500068.1, Max: 4500085.2, Diff: 24.9]

[Ext Root Scanning (ms): Min: 0.0, Avg: 4.8, Max: 31.8, Diff: 31.8, Sum: 231.0]

[Update RS (ms): Min: 0.0, Avg: 21.6, Max: 116.3, Diff: 116.3, Sum: 1036.3]

[Processed Buffers: Min: 0, Avg: 4.9, Max: 29, Diff: 29, Sum: 234]

[Scan RS (ms): Min: 0.0, Avg: 41.5, Max: 62.3, Diff: 62.2, Sum: 1992.1]

[Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.3]

[Object Copy (ms): Min: 195.6, Avg: 233.1, Max: 261.1, Diff: 65.5, Sum: 11189.0]

[Termination (ms): Min: 21.0, Avg: 45.6, Max: 74.4, Diff: 53.4, Sum: 2188.5]

[GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 4.8]

[GC Worker Total (ms): Min: 329.6, Avg: 346.7, Max: 354.7, Diff: 25.1, Sum: 16642.0]

[GC Worker End (ms): Min: 4500414.7, Avg: 4500414.8, Max: 4500415.0, Diff: 0.2]

193

194

Plot Showing Max Times

195

Plot Showing Avg Times

Humongous Objects Requirements

196

©2017 CodeKaram

Ideally, humongous objects are few in number and are short lived.

A lot of long-lived humongous objects can cause evacuation failures since humongous regions add to the old generation occupancy.

197

Humongous Objects

Presenter

Presentation Notes

External fragmentation happens when you are trying to allocate Hobjs into contiguous HRegions, but can’t find contiguous regions in the old generation. But once these HObj die the fragmentation dies with them.



Object Humongous


Humongous Objects

Presenter

Presentation Notes


©2017 CodeKaram

Humongous Objects:

• Are allocated out of the old generation

• Are not moved

*Note: Since JDK8 update 40, they can be collected during a

young collection

199

So, What Did We Observe?



Object Humongous


Wasted Space!

Humongous Objects

Presenter

Presentation Notes


©2017 CodeKaram

Humongous objects can pose the following issues:

Wasted space Evacuation failures due to not having enough (to-space) regions

201

So, What Did We Observe?

Fragmentation In The G1 Collector

202

©2017 CodeKaram

• G1 GC is designed to “absorb” some fragmentation.

• Default is 5% of the total Java heap

• Tradeoff so that expensive regions are left out.

G1 Heap Waste Percentage

203

Presenter

Presentation Notes

dead objects are allowed to remain in the old generation and hence there is garbage that stays around and so wriggle room for transient data is reduced.

©2017 CodeKaram

G1 Mixed GC (Region) Liveness Threshold

204

• G1 GC’s old regions are also designed to “absorb” some fragmentation.

• Default is 85% liveness in a G1 region.

• Tradeoff so that expensive regions are left out.

Presenter

Presentation Notes

Any region above 85% liveness is not included in any collection. dead objects are allowed to remain in the old regions and hence there is garbage that stays around and so wriggle room for transient data is reduced.

©2017 CodeKaram

Humongous Objects

205

• Wasted space!

• External fragmentation!

Presenter

Presentation Notes

External fragmentation happens when you are trying to allocate Hobjs into contiguous HRegions, but can’t find contiguous regions in the old generation. But once these HObj die the fragmentation dies with them.

©2017 CodeKaram

fragmentation can lead to evacuation failures!

206

Promotion/Evacuation Failures In The G1

Collector

207

©2017 CodeKaram

Evacuation Failures

208

276.731: [GC pause (G1 Evacuation Pause) (young) (to-space exhausted), 0.8272932 secs] [Parallel Time: 387.0 ms, GC Workers: 8] <snip> [Code Root Fixup: 0.1 ms] [Code Root Purge: 0.0 ms] [Clear CT: 0.2 ms] [Other: 440.0 ms] [Evacuation Failure: 437.5 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.1 ms] [Ref Enq: 0.0 ms] [Redirty Cards: 0.9 ms] [Humongous Reclaim: 0.0 ms] [Free CSet: 0.9 ms] [Eden: 831.0M(900.0M)->0.0B(900.0M) Survivors: 0.0B->0.0B Heap: 1020.1M(1024.0M)->1020.1M(1024.0M)] [Times: user=3.64 sys=0.20, real=0.83 secs]

**

Presenter

Presentation Notes

-Xlog:gc*,gc+phases=debug The "to-space exhaused" information is logged on a separate line in the new logging: [0,295s][info ][gc ] GC(11) To-space exhausted

©2017 CodeKaram

• When there are no more regions available for survivors or tenured objects, G1 GC encounters an evacuation failure.

• An evacuation failure is expensive and the usual pattern is that if you see a couple of evacuation failures; full GC could* soon follow.

209

Evacuation Failures

Presenter

Presentation Notes

Evacuation failures or promotion failures or to-space overflow or exhausted all refer to the same notion. For successfully copied objects, G1 needs to update the references and the regions have to be tenured. For unsuccessfully copied objects, G1 will self-forward them and tenure the regions in place.

©2017 CodeKaram

A heavily tuned JVM command line may be restricting the G1 GC ergonomics and adaptability.

Start with just your heap sizes and a reasonable pause time goal

210

Avoiding Evacuation Failures

©2017 CodeKaram

Your live data set + long live transient data may be too large for the old generation

Check LDS+ and increase heap to accommodate everything in the old generation.

211


©2017 CodeKaram

Initiating Heap Occupancy Threshold could be the issue.

Check IHOP and make sure it accommodates the LDS+.

IHOP threshold too high -> Delayed marking -> Delayed incremental compaction -> Evacuation Failures!

212


©2017 CodeKaram

Marking Cycle could be taking too long to complete?

Increase concurrent marking threads

Reduce IHOP

213


©2017 CodeKaram

to-space survivors are the problem?

Increase the G1ReservePercent, if to-space survivors are triggering the evacuation failures!

214


Presenter

Presentation Notes

If "to-space" survivor is the issue, then increase the -XX:G1ReservePercent. The default is 10% of the Java heap. G1 GC creates a false ceiling and reserves the memory, in case there is a need for more "to-space". Of course, G1 GC caps it off at 50%, since we do not want the end-user to set it to a very large value.

215

216

217

©2017 CodeKaram

• 487.817: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: region allocation request failed, allocation request: 524280 bytes]

• 487.817: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 524280 bytes, attempted expansion amount: 1048576 bytes]

• 487.817: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap already fully expanded]

• 487.888: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: recent GC overhead higher than threshold after GC, recent GC overhead: 28.40 %, threshold: 10.00 %, uncommitted: 0 bytes, calculated expansion amount: 0 bytes (20.00 %)]

218

©2017 CodeKaram

• 487.817: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: region allocation request failed, allocation request: 524280 bytes]

• 487.817: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 524280 bytes, attempted expansion amount: 1048576 bytes]

• 487.817: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap already fully expanded]

• 487.888: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: recent GC overhead higher than threshold after GC, recent GC overhead: 28.40 %, threshold: 10.00 %, uncommitted: 0 bytes, calculated expansion amount: 0 bytes (20.00 %)]

219

220

Additional Reading

221

©2017 CodeKaram

• Book: Java Performance Companion

• Mailing list: [email protected]

• Articles on InfoQ: https://www.infoq.com/profile/Monica-Beckwith

• GCHisto: https://www.openhub.net/p/gchisto

• JFreeChart: http://www.jfree.org/jfreechart/

222

https://www.amazon.com/Java-Performance-Companion-Charlie-Hunt/dp/0133796825/ref=sr_1_1?ie=UTF8&qid=1501268875&sr=8-1&keywords=java+performance+companion

https://www.amazon.com/Java-Performance-Companion-Charlie-Hunt/dp/0133796825/ref=sr_1_1?ie=UTF8&qid=1501268875&sr=8-1&keywords=java+performance+companion

mailto:[email protected]

mailto:[email protected]

https://www.infoq.com/profile/Monica-Beckwith

https://www.infoq.com/profile/Monica-Beckwith

https://www.openhub.net/p/gchisto

https://www.openhub.net/p/gchisto

http://www.jfree.org/jfreechart/

http://www.jfree.org/jfreechart/

Documents

The What & The Why of Automatic Memory …• Deep Dive into G1 GC 4 ©2017 CodeKaram Agenda - if time permits… • Allocations • Few Optimizations in OpenJDK HotSpot VM 5 ©2017