The G1 GC in JDK 9 - RainFocus G1 Garbage Collector in JDK 9 Quick intro to G1 in 2017 ... Class unloading with concurrent mark (JDK 8u40) 3) Eagerly reclaim humongous regions (JDK

Copyright © 2017, Oracle and/or its affiliates. All rights reserved.

The G1 GC in JDK 9

Erik DuvebladSenior Member of Technical StafOracle JVM GC TeamOctober, 2017

3


Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

4


The G1 Garbage Collector in JDK 9

Quick intro to G1 in 2017

Five major improvements since JDK 8

The future

1

2

3

5


Who am I?

• Erik Duveblad

• Master’s thesis on load balancing during GC

• Have worked with GC at Oracle for ~6 years

• Worked with the G1 GC for past 3 years

• > 150 commits to OpenJDK (Reviewer)





The future

1

2

3

7



• Garbage collection (GC) is a way to manage memory

• In Java, programmers do not need to explicitly manage memory:

• Compared to C where programmers must manage the memory:

What is garbage collection?

8

// Memory reclaimed by the GCString s = new String(“Hello GC!”);

char* s = malloc(sizeof(char)*10);

// Memory reclaimed by programmerfree(s);



• How does GC work?


9

Heap





10

Heap

Objects





11

Heap

Objects

Fields

...





12

Heap

Objects

Fields

References





13

Heap

Objects

Fields

References





14

Heap

Objects

Fields

References

Roots





15

Heap

Objects

Fields

References

Roots





16

Heap

Objects

Fields

References

Roots





17

Heap

Objects

Fields

References

Roots





18

Heap

Compaction


Quick intro to G1 in 2017What is G1?

19



Be wary when reading old blog posts, old documentation, etc.

What is G1?

20

2004

Paper published

2009

Experimental support(JDK 6u14)

2012

Official support(JDK 7u4)

Default(JDK 9)

2017



• The goal: throughput and low latency– Throughput – number of transactions per second

– Latency – maximum time of a transaction

• The default pause goal is 200 milliseconds

– Higher pause goal → more throughput, higher latency

– Lower pause goal → less throughput, lower latency

What is G1?

21



• The heap is split into multiple regions

• Region size depends on heap size, e.g. 2 MB for 4 GB heap

Generational region-based memory management

22

Heap



• New objects are allocated into eden (E) regions


23

E

E

E

Heap



• A young collection happens after a number of eden regions have been allocated


24

E

E

E

Heap



• Young collections compactly copy live objects in eden regions tosurvivor regions (S)


25

E S

E

E

Heap



• Objects will then continue to be allocated in eden regions


26

E S

E

E

Heap



• If objects survive multiple young collections, then they are compactly copied into an old region (O)


27

E S

S E

E

O

Heap



• After a while the heap fills up with eden, survivor and old regions


28

E O

O

O S O

S

O

E

E

EO

O

O

Heap



• All live objects in old regions are then marked concurrently

• The Java application is not stopped


29

E O

O

O S O

S

O

E

E

EO

O

O

Heap



• Eden, survivor and old regions are then collected in mixed collections.

• Live objects are compactly copied into survivor and old regions.


30

E O

O

O S O

S

O

E

E

EO

O

O

Heap






31

E O

O O

S

O S O

S

O

E

E

EO

O

O

Heap






32

O

S

O O

OO

O

O

Heap






33

O

S O

O

O

O

Heap



• When no more old regions are suitable for collection,then G1 will resume doing young collections


34

O

O

S

O

Heap



● G1 thus transitions between the following states


35

YC + CMYC

MC

Young collections

Young collections +concurrent mark

Mixed collections





The future

1

2

3

36

✓


Five major improvements to G1 since JDK 8

1) String deduplication (JDK 8u20)

2) Class unloading with concurrent mark (JDK 8u40)

3) Eagerly reclaim humongous regions (JDK 8u60)

4) Adaptive start of concurrent mark (JDK 9)

5) More efficient collections (JDK 9)

37








38


String deduplication (JDK 8u20)

39

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7

String conf = new String(“JavaOne”);

String j1 = new String(“JavaOne”);



confconf

j1j1



40

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7





confconf

j1j1

??



41

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7





confconf

j1j1

✓✓



42

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7

char[] value

int hash

j.l.String

‘J’ ‘a’ ‘v’ ‘a’ ‘O’ ‘n’ ‘e’

char[]

length: 7





confconf

j1j1

✓✓private and final!



43

● During a collection G1 adds all newly allocated Strings to a queue

● After the young collection, G1 concurrently checks if any two Strings equals

● If two Strings are identical, make them refer to the same char[]

● Note: not the same as String.intern()● String.intern() cares about String objects, deduplication about char[]● Uses diferent tables internally in the JVM



44

● Can save a lot of memory depending on your application

● Trade-of: will use slightly more CPU

● Trade-of: might cause slightly longer young collections

● Try it out with -XX:+UseStringDeduplication in JDK 8u20 and later!








45


Class unloading with concurrent mark (JDK 8u40)

46

CLCL

.class.class

.class.class

.class.class



47

CLCL

.class.class

.class.class

.class.class



48

CLCL

.class.class

.class.class

.class.class



49

CLCL

.class.class

.class.class

.class.class



50

…

JVM



51

…

JVM



52

…

JVM



53

…

JVM



54

● After all objects have been visited, thenunload all classes loaded by class loaders that

aren’t live

● Two algorithms in G1 visits all objects● Concurrent marking → tricky, but performant

● Fall-back full GC → easy, but slow

● In JDK 8u40 we shipped class unloading after concurrent marking



55

● Controlled by -XX:+ClassUnloadingWithConcurrentMark

● Enabled by default

● Reduces the need for fall-back full GCs

● Available in JDK 8u40 and later







5) More efficient young collections (JDK 9)

56


Eagerly reclaim humongous regions (JDK 8u60)

57

● When objects are larger than half a region, they are called humongous

● Humongous objects are stored in humongous regions

● G1 doesn’t copy humongous regions, too expensive

● Want to collect as early as possible to free up memory

Humongous object



58

● G1 keeps tracks of references between old regions:

● So if a humongous region has zero incoming references…

● …then only an object in a young region can keep it alive

O O O O O H O O



59

● During a young collection, G1 checks references to humongous regions

● If no references are found, then the humongous object can be collected!

O O O O O H O O

Y Y Y Y Y Y Y Y



60

● G1 can therefore reclaim humongous objects during a young collection!

● G1 does not need to wait for concurrent mark to finish

● Introduced in JDK 8u60







5) More efficient young collections (JDK 9)

61


Adaptive start of concurrent mark (JDK 9)

62

O

O

O

O

E

E

E

● Objects in old regions are mark concurrently

● Old regions can’t be collected until the concurrent mark finishes



63

O

O

O

O

E

E

E

● Concurrent marking must finish before the heap is full with old regions

● When should it be started?

OOOOO

O

O

OO

O O O O

OE



64

● Prior to JDK 9: -XX:InitiatingHeapOccupancyPercent (IHOP)

● Replaced in JDK 9 with an adaptive, dynamic calculation:

1) Use -XX:InitiatingHeapOccupancyPercent as initial value

2) Sample runtime data

3) Use data to make prediction

4) Always adds a safety margin!



65

● Results in less concurrent mark failures → less fall-back full Gcs

● Controlled with the flag -XX:+G1UseAdaptiveIHOP

● Enabled by default








66


More efficient collections (JDK 9)

67

Impoved PLAB sizing

Parallel freeing of collection set

Parallel promotion failure

Improved work distribution Enable TLAB resizing

Remembered set space reduction

Ergonomic thread tuning

Concurrent mark from roots

Parallel pre-touch

More concurrent data structures

Decrease Hot Card Cache Contention

Parallel clear of the next bitmap

Array-based collection set

Improved concurrent refinement

Improved clearing of card table

Cache align and pad from the card cache



68

Impoved PLAB sizing







Parallel pre-touch








250+enhancements



69

Impoved PLAB sizing







Parallel pre-touch








180+bug fixes



70

Impoved PLAB sizing







Parallel pre-touch








What is the effect?



71

● G1 has been picked up by major Java frameworks and applications● Especially GUI applications and server-side frameworks

● Many major companies have switched or are switching to G1● Particularly for low latency workloads…

● … where throughput also is important!

● Always run the latest JDK release!





The future

1

2

3

72

✓

✓


The future

73

● Great improvements for next JDK release● Parallel fall-back full GC - JEP 307● Faster card scanning


The future

74

● Continue to push G1 further● Rebuild remembered sets concurrently● Improved ergonomics


Stay connected

75

• Email: [email protected]

– Many experienced users

– Also read by GC developers● might not always have time to answer…

• IM: #openjdk @ irc.oftc.net

mailto:[email protected]


Stay connected

• Join us: DevOps Corner (Developer Lounge – Moscone West)

• Learn more: openjdk.java.net | wercker.com/java

• Follow: @OpenJDK, @wercker #JavaOne #DevOps

76

The G1 GC in JDK 9 - RainFocus G1 Garbage Collector in JDK 9 Quick intro to G1 in 2017 ... Class unloading with concurrent mark (JDK 8u40) 3) Eagerly reclaim humongous regions (JDK

Documents