Java Memory Management Overview

C O N F I D E N T I A L Apr 22, 2023 1

Java Memory Management Overview

Justin Chen

Mar 16rd, 2009


Before Start …

Learning HOW is more important than learning WHAT.知其然，更要知其所以然


Agenda

• How Java Object Stores in Memory

• Shallow Size, Retained Size and Weak Reference

• JVM Memory Structure & Heap Dump

• How GC works

• GC Algorithm

• Hints on GC Turning

• VisualVM and GCViewer

• Out of Memory – 3 types

• Memory Leak, Permanent Memory Leak, Native Memory Leak

• Memory Leak & Eclipse Memory Analyzer

• JDK 6


Size of Java Types & Objects

From Java Spec - byte : 8-bitshort : 16-bitInt : 32-bitlong : 64-bitchar : 16 bit unsigned integer

float : 32-bitdouble: 64-bitboolean: 1 bit?

Actual Memory Size - (depends on JVM Implementation)Byte : 16 bytesShort : 16 bytesInteger : 16 bytesLong : 16 bytesCharacter : 16 bytes

Float : 16 bytesDouble : 16 bytesBoolean : 16 bytes

So, how about Object?-new Object()-new

new Object() => 8 bytesnew Double[] itself => 16 bytes new ArrayList<Double> itself => 24 bytes

Why?Memory Layout of Boolean[HEADER: 8 bytes] 8 [value: 1 byte ] 9[padding: 7 bytes] 16


Shallow and Retained Sizes

Shallow Size : the amount of allocated memory to store the object itself. new ArrayList<Boolean>() = 24 bytes

Retained Size : shallow size + the shallow sizes of the objects that are accessible, directly or indirectly, only from this object. In other words, the retained size represents the amount of memory that will be freed by the garbage collector when this object is collected. new ArrayList<Boolean>() = 80 bytes

What’s GC root?


Weak Reference

• When strong reference are too strong– StringBuffer buffer = new StringBuffer(); – hashMap.put(key, value)– cache.add(image)

• Non-Strong Reference– An object referenced only by weak references is considered unreachable (or "weakly

reachable") and so may be collected at any time.

• Reference Strength: strong > soft > weak > phantom

• Soft Reference– Mostly often used to implement memory-sensitive caches– No constraints on GC time, but will be cleared before OOM

• Weak Reference– Weakly reachable object will be discarded at the next GC cycle

• Phantom Reference– An object is phantomly referenced after it has been finalized, but before its allocated

memory has been reclaimed.


Heap Dump

• The heap dump is a dump of all the live objects and classes. – Example: java_pid460.hprof.20090314.234647

• The ways to get Heap Dump (Sun Hotspot JVM 5.0 update 16)– -XX:+HeapDumpOnOutOfMemoryError

– -XX:+HeapDumpOnCtrlBreak

– use profiling tool, such as VisualVM

• You need a tool to analyze heap dump– Runtime Diagram, Visual VM

– Post-mortem analysis, Eclipse Memory Analyzer


User HeapUser Heap

JVM Memory Structure

PermanentPermanent

Native

All class instances

Arrays

-Xmx<size> max New/Old heap size

-Xms<size> initial New/Old heap size

per-class structures:

run-time constant pool, field and method data

codes for methods and constructors

Interned String

-XX:MaxPermSize

Eden

S0

S1

Old(tenured)

GC-ableHeap?

The memory managed by OS

New/Young

what is interned String?what is interned String?


How GC works? GC of Serial Collection

Empty Empty Survivor Spaces

Old

Eden

From To

New Object


How GC works? Full GC of Serial Collection

• Full GC: A old or permanent generation collection (Stop the world)

Before Full GC

After Full GC


GC Algorithm

• Serial Collector– as we described in previous slides

– default collector for client-class server

• Parallel Collector– Performing the young generation collection in parallel, old generation is same

– default collector for server-class server

– -XX:+UseParallelGC

• Parallel Compacting Collector– Performing the old generation collection in parallel comparing to parallec

collector

– Eventually, this collector will replace Parallel Collector in the future

– -XX:+UseParallelOldGC

• Concurrent Mark-Sweep (CMS) Collector (low-latency collector)– Shorter GC pauses, but need larger heap space and may cause fragmentation

– -XX:+UseConcMarkSweepGC


GC Algorithm Performance Metrics

• Throughput – High is betterThroughput – High is better– percentage of total time not spent in GC

• Garbage Collection Overhead– percentage of total time spent in GC

• Pause Time – Low is betterPause Time – Low is better– the length of Stop Time for GC

• Frequency of collection– how often collection occurs

• Footprint– a measure of size, such as heap size

• Promptness– The time between an object becomes garbage and when the memory

becomes available


Hints on GC Turning

• Enough Heap Size

• The proportion of Heap dedicated to the young generation– grant plenty of memory to young generation

– may cause excessive old generation collections or pause time

• Specify desired behaviour – for parallel collector or parallel compacting collector

– -XX:MaxGCPauseMillis=n

– -XX:GCTimeRatio=n 1/(1+n)

• Diagnosing a Garbage Collection problem– http://java.sun.com/docs/hotspot/gc1.4.2/example.html


GC Log

• -Xloggc:d:\gc.log

• -XX:+PrintGC

• -XX:+PrintGCDetails

• -XX:+PrintGCTimeStamps – add time stamp

3603.329: [GC [PSYoungGen: 244309K->4520K(244800K)] 705465K->472071K(978816K), 0.0274399 secs]

Young Gen: before GC->After GC All: before GC->after GC Pause Time

3603.357: [Full GC [PSYoungGen: 4520K->0K(244800K)] [PSOldGen: 467550K->407305K(734016K)] 472071K->407305K(978816K) [PSPermGen: 81712K->81712K(171136K)], 1.3827685 secs]


Visual VM

• Get Runtime Heap Dump

• Monitor

• Visual GC

time spent compiling Java byte codes into native code

TenuringThreshold & MaxTenuringThreshold also impacts performance


GC Viewer - Post-mortem analysis


Out of Memory - java.lang.OutOfMemoryError

• Java heap space– Configuration issue: -Xmx

– Memory Leak

– The excessive use of finalizers

• PermGen space– Too many classes: -XX:MaxPermSize

• Requested array size exceeds VM limit– Why need a so big array?

• Request <size> bytes for <reason>. Out of swap space?– Native Memory Leak?

• <reason> <stack trace> (Native method)– Native Memory Allocation Issue


Memory Leak vs. OOM

• Memory Leak (OOM != Memory Leak)– An unintentional memory usage.

– Java memory leaks are objects which are not used/needed anymore, but which are still reachable and therefore are not removed by the Garbage Collector.

• How Can We Find Leak – In most of cases, the biggest objects

• Who Caused Leak?– follow the reference chain from the object to the (GC) roots

• GC Roots– Objects on the call stack of the current thread (e.g. method parameters and

local variables)

– The thread itself and classes loaded by the system class loader

– custom class loaders are NOT


Eclipse Memory Analysis – Heap Memory Leak


Perm Memory Leak

• Too Many Interned String– String.intern()

– Constant String will be interned implicitly

– No Enough Info provided by Heap Dump on Interned String

– If Perm Memory increased dynamically, be careful

• Too Many Classes or Class Load Leak– Enlarge the perm generation

– Avoid duplicated class loader


Eclipse Memory Analyzer – Perm Generation

• Class Loader Explorer: Java Basic => Class Load Explorer

Class Loader NameClass Loader Name

Loaded Class NumberLoaded Class Number

Loaded Object NumberLoaded Object Number


List Duplicated Class Loaders

• Java Basic => Duplicated Classes


Out of Swap Space?

• Request <size> bytes for <reason>. Out of swap space?– Enlarge the swap space

– Systems with 4GB of ram or less require a minimum of 2GB of swap space

– Systems with 4GB to 16GB of ram require a minimum of 4GB of swap space

– For Unix Family OS, use pmdump or pmap, libumem for Solaris

# An unexpected error has been detected by SAP Java Virtual Machine: # java.lang.OutOfMemoryError: requested 2048000 bytes for eArray.cpp:80: GrET*. Out of swap space or heap resource limit exceeded (check with limits or ulimit)? # Internal Error (\\...\hotspot\src\share\vm\memory\allocation.inline.hpp, 26), pid=6000, tid=468


Native Memory Leak?

• <reason> <stack trace> (Native method)– Native Memory Allocation Issue

• C heap exhaustion is usually the result of a memory leak in either– VM itself

– Core library native code

– Third party native code

• Append -verbose:jni option after JVM args.– Observe the loading and linking actions of jni dynamic libs

• No many choices– Check JVM bugs


JDK 6 ! – Performance Enhancement

• Runtime Performance Improvement– Synchronization & Multiple Threads

– Array Copy

– Background compilation (Runtime Code Optimization)

• GC Performance Improvement– Parallel Compaction Collector

– Concurrent Low Pause Collector


Last but not least

• Let’s use powerful machine – 64 bit

– 4 - 8 CPU

– 16GB – 64GB Memory

• Unix Family OS– Why Java Runs on Windows?

– Solaris

– HP-UX

– Unit

– Linux

• However, Hardware cannot help you survive if the codes are However, Hardware cannot help you survive if the codes are rubbish!rubbish!


References

• http://www.codeinstructions.com/2008/12/java-objects-memory-structure.html

• http://wiki.eclipse.org/index.php/MemoryAnalyzer

• http://dev.eclipse.org/blogs/memoryanalyzer/2008/04/21/immortal-objects-or-how-to-find-memory-leaks/

• http://java.sun.com/javase/technologies/hotspot/gc/index.jsp

• http://java.sun.com/javase/technologies/hotspot/gc/memorymanagement_whitepaper.pdf

• http://www.tagtraum.com/gcviewer-vmflags.html#sun.verbose

• http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

• http://java.sun.com/performance/reference/whitepapers/6_performance.html#2

• http://java.sun.com/docs/hotspot/gc1.4.2/example.html

• http://blogs.sun.com/dagastine/entry/java_6_leads_out_of

• http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html

Java Memory Management Overview

Documents

Transcript of Java Memory Management Overview