The G1 GC in JDK 9. Erik Duveblad Senior Member of Technical Staf Oracle JVM GC Team October, 2017

Size: px

Start display at page:

Download "The G1 GC in JDK 9. Erik Duveblad Senior Member of Technical Staf Oracle JVM GC Team October, 2017"

Jack Nichols
6 years ago
Views:

4 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 racle s products remains at the sole discretion of racle. Copyright 2017, racle and/or its affiliates. All rights reserved. 4

6 Who am I? Erik Duveblad Master s thesis on load balancing during GC Have worked with GC at racle for ~6 years Worked with the G1 GC for past 3 years > 150 commits to penjdk (Reviewer) Copyright 2017, racle and/or its affiliates. All rights reserved.

8 Quick intro to G1 in 2017 What is garbage collection? Garbage collection (GC) is a way to manage memory In Java, programmers do not need to explicitly manage memory: // Memory reclaimed by the GC String s = new String( Hello GC! ); Compared to C where programmers must manage the memory: char* s = malloc(sizeof(char)*10); // Memory reclaimed by programmer free(s); Copyright 2017, racle and/or its affiliates. All rights reserved. 8

20 Quick intro to G1 in 2017 What is G1? Experimental support (JDK 6u14) fficial support Paper published (JDK 7u4) Default (JDK 9) 2017 Be wary when reading old blog posts, old documentation, etc. Copyright 2017, racle and/or its affiliates. All rights reserved. 20

21 Quick intro to G1 in 2017 What is G1? 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 Copyright 2017, racle and/or its affiliates. All rights reserved. 21

22 Quick intro to G1 in 2017 Generational region-based memory management The heap is split into multiple regions Region size depends on heap size, e.g. 2 MB for 4 GB heap Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 22

24 Quick intro to G1 in 2017 Generational region-based memory management A young collection happens after a number of eden regions have been allocated E E E Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 24

25 Quick intro to G1 in 2017 Generational region-based memory management Young collections compactly copy live objects in eden regions to survivor regions (S) E E S E Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 25

26 Quick intro to G1 in 2017 Generational region-based memory management bjects will then continue to be allocated in eden regions E E S E Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 26

27 Quick intro to G1 in 2017 Generational region-based memory management If objects survive multiple young collections, then they are compactly copied into an old region () E E S S E Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 27

28 Quick intro to G1 in 2017 Generational region-based memory management After a while the heap fills up with eden, survivor and old regions E E E S E S Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 28

29 Quick intro to G1 in 2017 Generational region-based memory management All live objects in old regions are then marked concurrently The Java application is not stopped E E E S E S Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 29

30 Quick intro to G1 in 2017 Generational region-based memory management Eden, survivor and old regions are then collected in mixed collections. Live objects are compactly copied into survivor and old regions. E E E S E S Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 30

31 Quick intro to G1 in 2017 Generational region-based memory management Eden, survivor and old regions are then collected in mixed collections. Live objects are compactly copied into survivor and old regions. E E E S S S E Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 31

32 Quick intro to G1 in 2017 Generational region-based memory management Eden, survivor and old regions are then collected in mixed collections. Live objects are compactly copied into survivor and old regions. S Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 32

33 Quick intro to G1 in 2017 Generational region-based memory management Eden, survivor and old regions are then collected in mixed collections. Live objects are compactly copied into survivor and old regions. S Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 33

34 Quick intro to G1 in 2017 Generational region-based memory management When no more old regions are suitable for collection, then G1 will resume doing young collections S Heap Copyright 2017, racle and/or its affiliates. All rights reserved. 34

35 Quick intro to G1 in 2017 Generational region-based memory management G1 thus transitions between the following states Young collections YC YC + CM MC Young collections + concurrent mark Mixed collections Copyright 2017, racle and/or its affiliates. All rights reserved. 35

37 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) Copyright 2017, racle and/or its affiliates. All rights reserved. 37

38 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 8u40) 4) Adaptive start of concurrent mark (JDK 9) 5) More efficient collections (JDK 9) Copyright 2017, racle and/or its affiliates. All rights reserved. 38

39 String deduplication (JDK 8u20) conf String conf = new String( Javane ); j.l.string char[] value char[] int hash length: 7 String j1 = new String( Javane ); J a v a n e j1 j.l.string char[] value char[] int hash length: 7 J a v a n e Copyright 2017, racle and/or its affiliates. All rights reserved. 39

40 String deduplication (JDK 8u20) conf j.l.string char[] value int hash? String conf = new String( Javane ); char[] String j1 = new String( Javane ); length: 7 J a v a n e j1 j.l.string char[] value char[] int hash length: 7 J a v a n e Copyright 2017, racle and/or its affiliates. All rights reserved. 40

41 String deduplication (JDK 8u20) conf j.l.string char[] value int hash String conf = new String( Javane ); char[] String j1 = new String( Javane ); length: 7 J a v a n e j1 j.l.string char[] value char[] int hash length: 7 J a v a n e Copyright 2017, racle and/or its affiliates. All rights reserved. 41

42 String deduplication (JDK 8u20) conf j.l.string char[] value int hash String conf = new String( Javane ); String j1 = new String( Javane ); char[] length: 7 J a v a n e j1 private and final! j.l.string char[] value char[] int hash length: 7 J a v a n e Copyright 2017, racle and/or its affiliates. All rights reserved. 42

43 String deduplication (JDK 8u20) 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 Copyright 2017, racle and/or its affiliates. All rights reserved. 43

44 String deduplication (JDK 8u20) 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! Copyright 2017, racle and/or its affiliates. All rights reserved. 44

45 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) Copyright 2017, racle and/or its affiliates. All rights reserved. 45

54 Class unloading with concurrent mark (JDK 8u40) After all objects have been visited, then unload 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 Copyright 2017, racle and/or its affiliates. All rights reserved. 54

55 Class unloading with concurrent mark (JDK 8u40) Controlled by -XX:+ClassUnloadingWithConcurrentMark Enabled by default Reduces the need for fall-back full GCs Available in JDK 8u40 and later Copyright 2017, racle and/or its affiliates. All rights reserved. 55

56 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 young collections (JDK 9) Copyright 2017, racle and/or its affiliates. All rights reserved. 56

57 Eagerly reclaim humongous regions (JDK 8u60) When objects are larger than half a region, they are called humongous Humongous object 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 Copyright 2017, racle and/or its affiliates. All rights reserved. 57

58 Eagerly reclaim humongous regions (JDK 8u60) G1 keeps tracks of references between old regions: H So if a humongous region has zero incoming references then only an object in a young region can keep it alive Copyright 2017, racle and/or its affiliates. All rights reserved. 58

59 Eagerly reclaim humongous regions (JDK 8u60) During a young collection, G1 checks references to humongous regions H Y Y Y Y Y Y Y Y If no references are found, then the humongous object can be collected! Copyright 2017, racle and/or its affiliates. All rights reserved. 59

60 Eagerly reclaim humongous regions (JDK 8u60) 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 Copyright 2017, racle and/or its affiliates. All rights reserved. 60

61 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 young collections (JDK 9) Copyright 2017, racle and/or its affiliates. All rights reserved. 61

62 Adaptive start of concurrent mark (JDK 9) bjects in old regions are mark concurrently ld regions can t be collected until the concurrent mark finishes E E E Copyright 2017, racle and/or its affiliates. All rights reserved. 62

63 Adaptive start of concurrent mark (JDK 9) Concurrent marking must finish before the heap is full with old regions When should it be started? E E E E Copyright 2017, racle and/or its affiliates. All rights reserved. 63

64 Adaptive start of concurrent mark (JDK 9) Prior to JDK 9: -XX:InitiatingHeapccupancyPercent (IHP) Replaced in JDK 9 with an adaptive, dynamic calculation: 1) Use -XX:InitiatingHeapccupancyPercent as initial value 2) Sample runtime data 3) Use data to make prediction 4) Always adds a safety margin! Copyright 2017, racle and/or its affiliates. All rights reserved. 64

65 Adaptive start of concurrent mark (JDK 9) Results in less concurrent mark failures less fall-back full Gcs Controlled with the flag -XX:+G1UseAdaptiveIHP Enabled by default Copyright 2017, racle and/or its affiliates. All rights reserved. 65

66 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) Copyright 2017, racle and/or its affiliates. All rights reserved. 66

67 More efficient collections (JDK 9) Decrease Hot Card Cache Contention Impoved PLAB sizing Parallel clear of the next bitmap Remembered set space reduction Improved concurrent refinement Parallel freeing of collection set Ergonomic thread tuning Parallel pre-touch Improved clearing of card table Parallel promotion failure Improved work distribution Enable TLAB resizing Concurrent mark from roots Cache align and pad from the card cache More concurrent data structures Array-based collection set Copyright 2017, racle and/or its affiliates. All rights reserved. 67

68 More efficient collections (JDK 9) Decrease Hot Card Cache Contention 250+ Impoved PLAB sizing Parallel clear of the next bitmap Remembered set space reduction Improved concurrent refinement Parallel freeing of collection set Ergonomic thread tuning Parallel pre-touch Improved clearing of card table Parallel promotion failure Improved work distribution Enable TLAB resizing enhancements Concurrent mark from roots Cache align and pad from the card cache More concurrent data structures Array-based collection set Copyright 2017, racle and/or its affiliates. All rights reserved. 68

69 More efficient collections (JDK 9) Decrease Hot Card Cache Contention 180+ Impoved PLAB sizing Parallel clear of the next bitmap Remembered set space reduction Improved concurrent refinement Parallel freeing of collection set Ergonomic thread tuning Parallel pre-touch Improved clearing of card table Parallel promotion failure Improved work distribution Enable TLAB resizing bug fixes Concurrent mark from roots Cache align and pad from the card cache More concurrent data structures Array-based collection set Copyright 2017, racle and/or its affiliates. All rights reserved. 69

70 More efficient collections (JDK 9) Decrease Hot Card Cache Contention Impoved PLAB sizing Parallel clear of the next bitmap Remembered set space reduction Improved concurrent refinement Parallel freeing of collection set What is the effect? Ergonomic thread tuning Parallel pre-touch Improved clearing of card table Parallel promotion failure Improved work distribution Enable TLAB resizing Concurrent mark from roots Cache align and pad from the card cache More concurrent data structures Array-based collection set Copyright 2017, racle and/or its affiliates. All rights reserved. 70

71 More efficient collections (JDK 9) 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! Copyright 2017, racle and/or its affiliates. All rights reserved. 71