memory management: what you need to know when moving to java 8

Memory ManagementWhat You Need To Know When Moving to Java 8

Todd Rader, Architect / Sales Engineer

AppDynamics

Market Leadership175% Bookings Growth 2013

1000+Customers

OUR

PLATFORM

Website download

Rapid Time to Value

Low cost of ownership

$Enterprise adoption

Scalable - largest APM deployments

On-Premise, SaaS, Hybrid

No professional Services

84Net Promoter Score

OUR

APPDYNAMICS

Copyright © 2014 AppDynamics. All rights reserved. 2


Agenda

• Memory Basics• …with a dive into metaspace

• Fun With Garbage Collectors• GC bake-off

• Summary/Conclusions• Q&A


Memory Basics: Types of Memory

STACK• Each thread has its own call stack• Adjust with -Xss• 64-bit JVMs need more stack size (8-byte references)• Default stack size: ????

Java7, jdk1.7.0_51, 64-bit on MacOS 10.9.6• Call depth before StackOverflowError: 10,827 (consistently)

Java8, jdk1.8.0_05, 64-bit on MacOS 10.9.6• Call depth before StackOverflowError: 20,000-ish (huh?)


Stack (cont’d)

FUN WITH NUMBERS….• With Java8 default stack size, call depth = 20,000-ish• Using –Xss1024k, same result (SO: default –Xss=1024k)• Using –XX:ThreadStackSize=1024, same result (-

XX:ThreadStackSize is another way of expressing –Xss)

Okay, but…

• -Xss512k result: 9000-ish• Not quite linear!

Need more memory space? Use a smaller –Xss value!• 200 threads * 512kb/thread = 100 MB saved!• What is your true stack size requirement?


Memory Basics: Types of Memory (cont’d)

HEAP• Eden/New vs. Survivor vs. Old/Tenured• “Ideal Object Death Rate”

• Eden >> Old >> Survivor


Heap (cont’d)

HEAP• What is your object survival demography?

• Caching!• Find out with:

• -XX:+PrintGCDetails• -XX:+PrintTenuringDistribution• -XX:+PrintGCTimestamps

• Adjust with:• -XX:NewRatio=n

– Example: NewRatio=2 (oldGenSize) = 2 * (newGenSize)

• -XX:NewSize=n (minimum)• -XX:MaxNewSize=n• -XX:MinFreeHeapRatio=n• -XX:MaxFreeHeapRatio=n


Heap: Java 6 HotSpot



META• PermGen in Java 6• PermGen (sort of) in Java 7• Metaspace in Java 8

while (true) { int length = rnd.nextInt(100); StringBuilder builder = new StringBuilder(); String chars = "abcdefghijklmnopqrstuvwxyz"; for (int i = 0; i < length; i++) { builder.append(chars.charAt(rnd.nextInt(chars.length()))); } interned.add(builder.toString().intern());}

What happens when this code is run?


Running the code…

JAVA 6Exception in thread "main" java.lang.OutOfMemoryError: PermGen space

• …in about 8 seconds!

JAVA 7Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

• …and it takes a long time to happen!

JAVA 8• Similar result as with Java 7


What happened???

JAVA 6PermGen contains:• Class meta data• Interned strings

JAVA 7• Interned strings moved to Metaspace

JAVA 8• Class meta data also moved to Metaspace


Metaspace

REPLACEMENT FOR PERMGEN• NOT JVM memory – native memory!

• BEA/Oracle JRockit• IBM JVM

SOME NEW STARTUP FLAGS• -XX:MetaSpaceSize=n (initial size)• -XX:MaxMetaSpaceSize=n• -XX:MaxMetaspaceExpansion=n• -XX:MaxMetaspaceFreeRatio=n• No default values for size! Max metaspace size is unlimited :-0

• Say goodbye to PermGen problems……right? Right?


More Metaspace

OBSOLETES SOME OLD STARTUP FLAGS• All of the “-XX:*Perm*” flags

NEW MEMORY POOL OBJECTS• No more matching on “Perm” for pool name


What does this mean?

NO MORE OOM/PERMGEN• But metaspace errors don’t go away • Monitor metaspace, not PermGen• Use –XX:MaxMetaSpaceSize?

• No you will never run out of metaspace• …but your use of native memory can grow unbounded!

• Yes you merely replace “OutOfMemory: PermGen space” with “OutOfMemory: Metaspace”

MONITOR METASPACE• Apps that leak metadata will still leak metadata• Gobbling up metaspace affects the entire system, not just the JVM

• Remember: native memory!


Monitoring Metaspace

COMMERCIAL SOLUTIONS• Expect (demand!) metaspace monitoring support to go along with

Java 8 support

JAVA MANAGEMENT BEANS• Update any querying of MBeans to search for Metaspace memory

pool instead of PermGen pools.

JVISUALVM• Metaspace monitoring supported

• …at least in the jvisualvm that is bundled with Jdk1.8.0_05 on MacOS!



DIRECT• sun.misc.Unsafe

• Used by the JDK (nio classes, for example)

• Out of the scope of this talk!


Let’s talk garbage…

PARALLEL GC• Default on Java 7, Java 8

• ParNewGC is the default on Java 6

• Does parallel compaction in Java 6 and 7• -XX:+UseParallelOldGC option in Java 5

CONCURRENT MARK AND SWEEP GC• NOT compacting!• Can be prone to fragmentation of old gen

• very bad full GCs result

G1GC• Only use after jdk1.7.0_u4!• “Experimental” in previous releases


The GC Bake-off

GC KILLER PROGRAM• Allocates lots of java.lang.Objects• Allocates fewer long Strings• Keeps objects around for varying lengths of times• Checks heap memory availability

• When low, thousands of memory references are let go of

• No GC tuning options used• 15-minute runs (killed with Ctrl-C)• Java 7 vs. Java 8


Java 7, Parallel GC


Java 7, Parallel GC

HIGHLIGHTS• No “-XX” option to enable (default)• Heap usage varied between 1500-2750 MB• Reasonable time spent in GC (1.6 seconds/minute)• No major collections


Java 7, ConcMarkSweepGC



HIGHLIGHTS• Enabled with –XX:+UseConcMarkSweepGC• Heap usage held steady around 2000 MB• Huge amount of time spent in GC (24 seconds/minute!)• No major collections


Java 7, G1GC


Java 7, G1GC

HIGHLIGHTS• Enabled with –XX:+UseG1GC• Heap usage varied between 750-2800 MB• Very reasonable time spent in GC (0.6 seconds/minute)• No major collections


The winner for Java 7

G1!• Less time spent in GC• Heap usage max barely more than max using Parallel

• CMS max heap usage was only 2000• CMS min was also near 2000 (very steady)

• Heap usage min best of all three• No major collections• BUT:

• Remember, no GC tuning parameters were used• DO NOT USE G1GC before jdk1.7.0_04

• “Experimental” in prior releases


Java 8, Parallel GC


Java 8, Parallel GC

HIGHLIGHTS• Incrementally worse than ParallelGC on Java 7

• Higher max heap (2950 vs. 2750)• Higher min heap (1700MB vs. 1500MB)• Roughly the same GC time (1.6 seconds/minute)

• No major collections



HIGHLIGHTS• Just……lousy

• HUGE amount of initial time spent in gc• 55 seconds/minute!

• Heap usage steadily declined• From 3000MB to 2000MB

• With all that time spent, you’d think a major collection would be avoided• You’d be wrong • The only run with a major collection


Java 8, G1GC


Java 8, G1GC

HIGHLIGHTS• Incrementally worse than G1/Java 7

• Heap usage max 2850MB vs. 2800MB• GC time .8 seconds/minute vs. .6 seconds/minute

• No major collections


The winner for Java 8, and overall

G1 AGAIN!• CMS not even close• G1 on Java 7 overall winner• Caveats:

• No GC tuning parameters used• Heap-only: very little metadata memory used• MacOS 10.9.4 (Maverick’s)• 2.8 GHz Intel Core i7 processor• 16 GB 1600 MHz memory• Java 7: jdk 1.7.0_51 for MacOS• Java 8: jdk 1.8.0_05 for MacOS


GC Tuning

OUT OF SCOPE • 600+ “-XX:” options

• 83 for CMS in Java 7• 82 for CMS in Java 8

• No love for CMSTriggerPermRatio!

• 24 for G1 in Java 7 and 8• Too many to cover!


Summary

• Know your object demography• Monitor your metaspace

• Interned strings• Class metadata

• Research the best GC• Watch out for outdated information

• G1GC tests before jdk1.7.0_04

• Re-think CMS GC?• Un-tuned CMS results far worse

FREE trial available:

www.appdynamics.com

Thank you

memory management: what you need to know when moving to java 8

Software

metaspace java

metaspace copyright

appdynamics copyright

metaspace memory pool

code java

n copyright

memory space

java heap space