How to collect your garbage - algorithmic edition - Bogdan Ghidireac Why? Why? Garbage collection • Automatic recycling of dynamically allocated memory • First attempts around 1959 Tracing • Mark all objects that are still referenced • Label marked object as “live” • Non labeled objects are reclaimed Tracing Tracing root object (live threads, stack local, …) JVM • Java Virtual Machine • Automatic garbage collection • Several GC strategies GC stages GC stages 1. mark GC stages 2. sweep GC stages 3. compact Variations • Mark and Sweep • Copying (all-in-one) Copying collector 3 phases in one pass Copying collector 3 phases in one pass Copying collector Copying collector new objects are allocated Copying collector garbage collection Copying collector garbage collection Generations • Most objects die young • Two generations, two collectors Generations young old Generations young copy collector survivor 0 survivor 1 eden CMS collector old tenured Generations eden • • • • survivor 0 survivor 1 Collect Eden -> copy to Survivor 0 Collect Eden + Survivor 0 -> copy to Survivor 1 Collect Eden + Survivor 1 -> copy to Survivor 0 Collect Eden + Survivor 0 -> copy to Survivor 1 Generations copy collector young CMS collector old What about my app? • Choose the collector based on app behavior • Monitor the GC with visualVM/visualGC or jstat • GC tuning is a mix of science and sorcery Visual VM/GC jstat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 S0 68.44 68.44 68.44 68.44 0 25.12 31.87 0 0 56.55 56.55 56.55 56.55 0 S1 0 0 0 25.17 37.04 37.04 0 99.19 99.19 0 0 0 0 0 E 28.76 67.01 88.66 100 42.28 100 46.46 13.23 86.62 0 0 0 0 44.4 O YGC YGCT FGC FGCT 82.75 28 16.344 0 0 82.75 28 16.344 0 0 82.75 28 16.344 0 0 84.61 29 16.344 0 0 87.91 29 17.137 0 0 88.13 30 17.137 0 0 91.12 30 17.659 0 0 91.82 31 17.709 0 0 91.82 31 17.709 0 0 91.86 32 17.987 1 0 91.86 32 17.987 1 0 91.86 32 17.987 1 0 91.86 32 17.987 1 0 36.01 32 17.987 1 8.94 Stateless web service • Lots of short lived objects (http requests) • Focus on young generation – Allocate enough memory for young generation – Use a parallel copy collector (ParNewGC) – Monitor object promotions; the http requests objects should not be promoted Large memory cache • Lots of long lived objects (cached objects) • Focus on old generation – Use a concurrent collector (CMS) – Monitor object promotions; only cached objects should be promoted – You cannot avoid a full GC but you can delay it ! Conclusions • GC is predictable if you understand how it works • Analyze and monitor your application before choosing the GC Appendix - G1 Appendix - C4 Barrier Translation Look-aside Buffer Resources • Understanding Java Garbage Collection – http://www.azulsystems.com/resources/understanding-java-garbagecollection • Java Garbage Collection Distilled – http://www.infoq.com/articles/Java_Garbage_Collection_Distilled • JVM performance optimization – http://www.javaworld.com/javaworld/jw-08-2012/120821-jvm-performanceoptimization-overview.html Q&A