Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Garbage First Garbage Collector (G1 GC): Current and Future Adaptability and Ergonomics.

6,255 views

Published on

G1 GC Presentation @ JavaOne 2013

Sneak a peek under the hood of the latest and coolest garbage collector, Garbage-First!
Dive deep into G1's adaptability and ergonomics
Discuss the future of G1's adaptability

Published in: Technology
  • Be the first to comment

Garbage First Garbage Collector (G1 GC): Current and Future Adaptability and Ergonomics.

  1. 1. Garbage-First Collector: Current and Future Adaptability and Ergonomics. Monica Beckwith Charlie Hunt John Cuthbertson
  2. 2. What's the talk about? 2  Sneak a peek under the hood of the latest and coolest garbage collector, Garbage-First!  Dive deep into G1's adaptability and ergonomics  Discuss the future of G1's adaptability
  3. 3. About the Presenters 3  Charlie Hunt Architect, Performance Engineering, Salesforce  Monica Beckwith Performance Architect, Servergy  John Cuthbertson GC Guru, Azul Systems
  4. 4. Agenda  Key Concepts  Definition  Ergonomics  Adaptability (if any)  Future Adaptability Needs of G1  Need More Information?  Questions? - Let‟s Discuss! 4
  5. 5. Key Concepts  Remembered Sets (RSets)  Marking Threshold and Concurrent Cycle  Collection Set (CSet) and Collections  Mixed Collection  Young Collection  Old Regions Collection  Humongous Allocations  Evacuation Failures  Reference Processing 5
  6. 6. Key Concept – Remembered Sets 6
  7. 7. Remembered Sets  Per-region entries  Each RSet keeps track of outside references into its “owning” region  RSets help regions to be independently GC‟d  No need to scan the entire heap!  G1 maintains RSets for –  old-to-young and  old-to-old references 7
  8. 8. Remembered Sets (RSets) 8 Region 2 Region 1 Region 3 RSet for Region 1 RSet for Region 3 RSet for Region 2 * Figure referenced from InfoQ article: http://www.infoq.com/articles/tuning-tips-G1-GC
  9. 9. RSets – Ergonomics and Adaptability  Concurrent Refinement threads –  Help maintain RSets  Concurrent updating  Post-write Barriers –  After a write  Help track cross region updates  Coarsening –  RSets transitioning through different levels of granularity 9
  10. 10. RSet - Concurrent Refinement  Concurrent processing of the filled update buffers  Tiered deployment  Max number can be set by -XX:G1ConcRefinementThreads  The processing of update buffers can eventually fall to the mutator (application) threads  Need to avoid such a scenario 10
  11. 11. RSet - Coarsenings  Three levels of granularity –  Sparse  Hash table of card indices; Fastest to scan  Fine  Card indices held in a bitmap; Scan not as fast as Sparse table  Coarse  One bit for each region; Slowest to scan 11
  12. 12. Key Concept – Marking Threshold and Concurrent Cycle 12
  13. 13. Marking Threshold and Concurrent Cycle  Threshold default: 45% of your Java heap  -XX:InitiatingHeapOccupancyPercent=<value>  When threshold‟s crossed, G1 starts a concurrent cycle  Some phases are concurrent and some are stop-the world  Multi-phased concurrent marking cycle finds the “best” regions to be collected  Live-ness accounting 13
  14. 14. Marking Threshold and Concurrent Cycle  After the marking phase is complete, G1 has information on which old regions to collect  Regions are ordered based on “collection efficiency”  Expensive regions would be regions with lots of live data and large RSets  Completely free regions are collected during cleanup phase  Examples are shown later in this presentation … 14
  15. 15. Marking Threshold – Example 1 15 Default IHOP IHOP increased to 75% Java heap size Java heap sizeMax heap occupancy Max heap occupancy Marking Threshold Marking Threshold
  16. 16. Marking Threshold – Example 2 16 Default IHOP IHOP increased to 70% 25% Young GCs 60% Mixed GCs 30% Mixed GCs 64% Young GCs Better to do more young GCs than mixed GCs
  17. 17. Key Concept – Collection Set and Collections 17
  18. 18. Collection Set  A set of regions to be collected during a GC evacuation pause  Young Collection will have only and all young regions in the CSet  Mixed Collection will have both young and old regions in the CSet  Live data in the CSet is evacuated/copied during a GC cycle 18
  19. 19. Collection Set – Young Collection Look for the following in PrintAdaptiveSizePolicy enabled log – 6676.431: [GC pause (G1 Evacuation Pause) (young) 6676.431: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 147002, predicted base time: 42.39 ms, remaining time: 157.61 ms, target pause time: 200.00 ms] 6676.431: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 950 regions, survivors: 74 regions, predicted young region time: 160.72 ms] 6676.431: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 950 regions, survivors: 74 regions, old: 0 regions, predicted pause time: 203.11 ms, target pause time: 200.00 ms] 19
  20. 20. Collection Set – Mixed Collection 5884.952: [GC pause (G1 Evacuation Pause) (mixed) 5884.952: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 167183, predicted base time: 48.30 ms, remaining time: 151.70 ms, target pause time: 200.00 ms] 5884.952: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 952 regions, survivors: 72 regions, predicted young region time: 225.39 ms] 5884.954: [G1Ergonomics (CSet Construction) finish adding old regions to CSet, reason: reclaimable percentage not over threshold, old: 134 regions, max: 308 regions, reclaimable: 1285706456 bytes (9.98 %), threshold: 10.00 %] 5884.954: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 952 regions, survivors: 72 regions, old: 134 regions, predicted pause time: 354.55 ms, target pause time: 200.00 ms] 20
  21. 21. Collection Set – Mixed Collection 21 Young Regions Old Regions H Humongous Regions ✓ ✓ ✓ ✓ ✓ H ✓ ✓ ✓ H ✓ H ✓ * Figure shows both young and old collection sets.
  22. 22. Mixed Collection - Copying 22 ✓ ✓ ✓ ✓ ✓ H ✓ ✓ ✓ H ✓ H ✓ Live objects are copied into the “to-space” regions: - Survivor Regions - Old Regions
  23. 23. Mixed Collection – Reclamation 23 ✓ ✓ ✓ ✓ ✓ H ✓ ✓ ✓ H ✓ H ✓ G1 achieves compaction via copying
  24. 24. CSet – Ergonomics and Adaptability  CSet for young entirely depends on –  The pause time target  -XX:MaxGCPauseMillis=<value>  All young regions are included in the CSet  CSet for mixed collection –  Could have a minimum number of regions based on the MixedGCCountTarget and  But will never cross the max number of regions set by OldCSetThresholdPercent 24
  25. 25. CSet – Ergonomics and Adaptability  -XX:G1MixedGCCountTarget (defaults to 8) – sets a target for mixed collections by setting a minimum limit on the old regions to collect per mixed collection, the goal is to not exceed the CountTarget during the mixed collection cycle  -XX:G1OldCSetRegionThresholdPercent (defaults to 10) – sets an upper limit on the max number of old regions that can be collected during a mixed collection (its expressed as a percentage of the total heap) 25
  26. 26. CSet – Ergonomics and Adaptability Snippets from a PrintAdaptiveSizePolicy enabled log –  <finish adding old regions to CSet, reason: predicted time is too high, predicted time: 2.27 ms, remaining time: 0.00 ms, old: 12 regions, min: 12 regions>  <finish adding old regions to CSet, reason: old CSet region num reached min, old: 142 regions, min: 142 regions>  <finish adding old regions to CSet, reason: reclaimable percentage not over threshold, old: 134 regions, max: 308 regions> 26
  27. 27. Mixed Collection – Ergonomics and Adaptability  Young regions – all young regions are included in a collection  Old regions are selected based on –  -XX:G1MixedGCLiveThresholdPercent (defaults to 65) – sets a limit on the live objects' occupancy such that any old region above that threshold will not be included in any mixed collection  Remember GC efficiency?  -XX:G1HeapWastePercent (defaults to 10) – sets the waste target i.e. the percentage of heap space you are willing to never collect in an effort to avoid expensive GCs  Remember the logs outputs that mentioned “reclaimable percentage not over threshold”? 27
  28. 28. Young Collection – Ergonomics and Adaptability  Young generation size is based on your pause time target and internally set min and max bounds  -XX:MaxGCPauseMillis = 200 (default)  Default min nursery size = 5% of your Java heap  Default max nursery size = 60% of your Java heap  Prediction logic  Determines how much time it will take to collect 1 region  (Re-)Sizes the young generation accordingly after each collection 28
  29. 29. Old Regions Collection - Ergonomics  During Mixed GCs  Based on the criteria mentioned earlier 809.925: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 4273 regions, reclaimable: 111102028112 bytes (53.89 %), threshold: 10.00 %] 29
  30. 30. Old Regions Collection - Ergonomics  During concurrent cycle  Entirely free (i.e. full of garbage) regions are collected 6530.615: [GC cleanup 13G->12G(18G), 0.0388540 secs]  During Full GCs  Collects and compacts all regions 154.725: [Full GC 1018M->369M(1024M), 1.6437640 secs] [Eden: 0.0B(51.0M)->0.0B(51.0M) Survivors: 0.0B->0.0B Heap: 1018.3M(1024.0M)->369.4M(1024.0M)] 30
  31. 31. Key Concept – Humongous Allocations 31
  32. 32. Humongous Objects –What Are They?  Objects that span >= 50% of G1‟s region size  Ideally –  Not that many in number  Are long lived  Allocated directly into the old generation into Humongous Regions  Avoids unnecessary copying back and forth and expensive promotions  Larger objects will need contiguous regions 32
  33. 33. Humongous Objects – WWG1D? 33 G1 Region – Young Generation G1 Region – Old Generation Object 1 < 50% of G1 Region Object 2 == 50% of G1 Region Object 3 > 50% of G1 Region Object 4 > G1 Region ?
  34. 34. Humongous Objects – WWG1D? 34 G1 Region – Young Generation G1 Region – Old Generation Object 1 < 50% of G1 Region Object 2 == 50% of G1 Region Object 3 > 50% of G1 Region Object 4 > G1 Region * Object 4 will need contiguous regions
  35. 35. Object 4 - Humongous Humongous Objects 35 Object 1 – NOT Humongous Object 2 - Humongous Object 3 - Humongous * Object 4 needs contiguous regions Wasted Space
  36. 36. Humongous Objects – What’s The Catch?  As of 7u40, initial heap size (-Xms) determines the region size  G1 strives for 2048 regions  Region size a factor of 2 ranging from 1M to 32M  If there is a vast difference between the initial and the max heap, normal objects may seem humongous to G1! 36
  37. 37. Humongous Objects – What’s The Catch?  Let‟s look at this PrintAdaptiveSizePolicy enabled log snippet (Note: G1 region size was 4MB):  1361.680: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 1459617792 bytes, allocation request: 4194320 bytes, threshold: 1449551430 bytes (45.00 %), source: concurrent humongous allocation] 37
  38. 38. Humongous Objects – What’s The Catch?  Notes from earlier snippet –  Concurrent cycle requested  Reason: Occupancy was higher than threshold  Allocation size was 4194320 bytes  Greater than 4MB, hence humongous allocation  Notes from the log (not shown here) –  Too many humongous allocations  Concurrent cycles can‟t keep up with the allocations  Resulting in to-space exhausted messages and eventually Full GCs 38
  39. 39. Humongous Objects – How to “Fix” it?  Let‟s find a region size that can accommodate the humongous objects as regular allocations  So the next region size up would be 8MB  But, 4.000015MB > 50% of 8MB  So, go to the next size up. i.e. 16MB  Solution – Set your region size to 16MB  -XX:G1HeapRegionSize=16M 39
  40. 40. Humongous Allocation – Ergonomics  Humongous Regions are not included in a mixed collection  Dead Humongous objects are collected during cleanup and during Full GC 6569.877: [GC cleanup 6708M- >6384M(12G), 0.0181200 secs]  Live Humongous objects are compacted through during full GC 40
  41. 41. Key Concept – Evacuation Failures 41
  42. 42. Evacuation Failures  Evacuation failures indicate that G1 ran out of heap regions either –  while copying to survivor regions or  while promoting or copying live objects in-to the old generation  Prior to Java 7u40 evacuation failures shown as a “to-space overflow” in the GC logs  Java 7u40 onwards shows “to-space exhausted” in the GC logs 42
  43. 43. Evacuation Failures – How to Avoid Them?  Get a baseline with bare minimum options:  -Xmx, -Xms and -XX:MaxGCPauseMillis=<value>  Over-tuning is NOT for G1  Look at the output of PrintAdaptiveSizePolicy  Too many humongous allocations?  Increase G1HeapRegionSize 43
  44. 44. Evacuation Failures  Plot the heap utilization stats from the log  Marking threshold too high?  Can‟t keep up with promotions  Marking threshold too low?  Not reclaiming much space from marking cycle  Concurrent cycles taking a long time to complete?  Increase the thread count: ConcGCThreads 44
  45. 45. Evacuation Failures  Sometimes survivor space gets exhausted  Increase the G1ReservePercent  It‟s a false ceiling  Defaults to 10  G1 will cap it off at 50% 45
  46. 46. Key Concept – Reference Processing 46
  47. 47. Reference Processing 47 0 10 20 30 40 50 60 70 80 90 100 [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause User Time (in secs) System Time (in secs) Real Time (in secs) Scaling
  48. 48. Reference Processing 48 9185.651: [GC remark 9185.653: [GC ref-proc, 5.2216490 secs], 5.2946850 secs] [Times: user=5.62 sys=0.00, real=5.29 secs] [Other: 339.7 ms] [Choose CSet: 0.0 ms] [Ref Proc: 287.8 ms] [Ref Enq: 5.4 ms] [Free CSet: 6.9 ms] This is not good!
  49. 49. Parallel Reference Processing 49 0 10 20 30 40 50 60 70 80 90 100 [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause [GCpause remark [GCpause User Time (in secs) System Time (in secs) Real Time (in secs) Scaling After enabling -XX:+ParallelRefProcEnabled
  50. 50. Parallel Reference Processing 50 9095.305: [GC remark 9095.309: [GC ref-proc, 0.4888450 secs], 0.5621620 secs] [Times: user=7.84 sys=0.03, real=0.56 secs] [Other: 91.0 ms] [Choose CSet: 0.0 ms] [Ref Proc: 43.9 ms] [Ref Enq: 1.0 ms] [Free CSet: 7.4 ms] Ooh yeah, much better!
  51. 51. Future Adaptability 51
  52. 52. Future Adaptability  Adaptive marking threshold?  A static value doesn‟t cut it  CMS has adaptive marking threshold with static override and static max value  Wouldn‟t it be nice if G1 had an adaptive threshold and adaptive max value?  Adaptive region size?  Will help alleviate the issues that applications with numerous short-lived “humongous” objects encounter 52
  53. 53. Future Adaptability  Avoiding evacuation failures  http://bugs.sun.com/bugdatabase/view_bug.do?bug _id=8014019  Reducing the cost of evacuation failures  http://bugs.sun.com/bugdatabase/view_bug.do?bug _id=8003237  http://bugs.sun.com/bugdatabase/view_bug.do?bug _id=8003235 53
  54. 54. Future Adaptability  Improving RSets  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187490  Improving concurrent refinement thresholds to reduce the possibility of long RSet updating times.  Smarter/ adaptable criteria for selecting CSet for old regions  Smarter/ adaptable Mixed Collections  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173711 54
  55. 55. Want More Info? 55
  56. 56. G1 Articles on the Web  http://www.infoq.com/articles/G1-One-Garbage-Collector-To- Rule-Them-All  http://www.infoq.com/articles/tuning-tips-G1-GC  http://www.oracle.com/technetwork/articles/java/g1gc- 1984535.html  http://www.infoq.com/presentations/java-g1  https://oracleus.activeevents.com/connect/sessionDetail.ww?SE SSION_ID=6583  https://blogs.oracle.com/javatraining/entry/getting_started_with _the_g1 56
  57. 57. Questions? Let‟s discuss „em! 57
  58. 58. More Questions? HOL5429: Tuning Low-Pause Garbage Collection – Tue 10 am CON3754: G1 GC: Migration to, Expectations, and Advanced Tuning – Wed 10 am CON7624: Understanding Java Garbage Collection and What You Can Do About It. – Wed 11:30 am GC Tuning BOF4020 - Tonight @7:30 pm JVM Performance BOF4471 – Tonight @8:30 pm Email: hotspot-gc-use@openjdk.java.net & hotspot-gc- dev@openjdk.java.net 58

×