Java Garbage Collection

Java Garbage Collection

JDK provides several garbage collection algorithms to meet different needs in different cases.

One aspects of performance tuning of Java application is to select suitable GC based on application's limitation on a desired maximum GC pause goal, a desired application throughput goal, minimum footprint.

Garbage Collection Algorithms

Design Choices

Serial versus Parallel

Concurrent versus Stop-the-world

Compacting versus Non-compacting versus Copying

Serial Collector(-XX:+UseSerialGC)

In Java 5, the serial collector is automatically chosen as the default garbage collector on machines that are not server-class machines

Parallel Collector(-XX:+UseParallelGC)

In Java 5, the parallel collector is automatically chosen as the default garbage collector on server-class machines

It is suitable for applications that run on machines with multi-processors and do not have pause time constraints, since infrequent, but potentially long, old generation collections will still occur.

Parallel Compacting Collector(-XX:+UseParallelOldGC)

The parallel compacting collector was introduced in J2SE 5.0 update 6.

Eventually, the parallel compacting collector will replace the parallel collector.

Concurrent Mark-Sweep (CMS) Collector(-XX:+UseConcMarkSweepGC)

The CMS collector is the only collector that is non-compacting.

CMS collector is suitable if your application needs shorter garbage collection pauses.

The Garbage-First Garbage Collector

This is firstly introduced in Java 1.6 Update 14, and is the long-term replacement for HotSpot's low-latency Concurrent Mark-Sweep GC.

G1 is a "server-style" GC and has attributes: Parallelism and Concurrency, Generational, Compaction, Predictability.

Garbage Collection Change in JDK versions

Enhancements in JDK 5.0

Garbage Collector (GC) has changed the default GC algorithm from the previous serial collector (-XX:+UseSerialGC) to a parallel collector (-XX:+UseParallelGC).

Ergonomics -- Automatic Selections

In Java 5, default values for the garbage collector, heap size, and HotSpot virtual machine type (client or server) are automatically chosen based on the platform and operating system on which the application is running.

This can better match the needs of different types of applications and require fewer command line options.

Ergonomics - Support behavior based tuning

Prior to Java 5.0 tuning, you tune garbage collection by principally of specifying the size of the overall heap, possibly the size of the generations in the heap, the size of the survivor spaces, the threshold for promotion from the young generation to the old generation.

This is complex and requires experiments and profiling carefully.

From Java 5.0, we can specify desired behavior by Maximum pause time goal -XX:MaxGCPauseMillis= and Application throughput goal(-XX:GCTimeRatio=), JVM would tune the size of the heap to meet the specified behavior.

Enhancements in JDK 6

Parallel compaction is used by default in JDK 6.

Parallel Compaction Enhancements(-XX:+UseParallelOldGC)

Parallel compaction is a feature that enables the parallel collector to perform major collections in parallel

Parallel Compaction was introduced in JDK 5.0 update 6, JDK 6 contains significant performance improvements.

CMS Enhancements(-XX:+ExplicitGCInvokesConcurrent)

The Concurrent Mark Sweep Collector has been enhanced to provide concurrent collection for the System.gc() and Runtime.getRuntime().gc() method instructions.

Garbage-First Garbage Collector

Java 1.6 Update 14 includes the initial preliminary version of the new Garbage First algorithm that is the long-term replacement for HotSpot's low-latency Concurrent Mark-Sweep GC.

Garbage Collection Ergonomics Improvement

Larger Default Young Generation Size

In Java 5, it allows users to specify a desired behavior by setting Maximum pause time goal -XX:MaxGCPauseMillis= and Application throughput goal(-XX:GCTimeRatio=), In Java 6, the default selections have been further enhanced to improve application runtime performance and garbage collector efficiency.

GC technique

Reference counting

The runtime keeps track of how many live objects point to a particular object at a given time.

It is fairly efficient, except for the obvious flaw that cyclic constructs can never be garbage collected.

Tracing techniques (Mark and Sweep)

Mark all objects currently seen by the running program as live. Then recursively mark all objects reachable from those objects live as well,

After that, other objects are thought as unreachable and can be garbage collected.

Root set

The root set includes all Java objects on local frames and contains global data, such as static fields.

Mark and sweep

This is the basis of all the garbage collectors in all commercial JVMs today.

Generational garbage collection

This is based on the observation that most objects are temporary or short-lived, the objects that already exist for a while are very likely to continue to exist.

Few references from older to younger objects exist.

Memory is divided into generations; separate pools hold objects of different ages. Different algorithms can be used to perform garbage collection in the different generation, each algorithm optimized based on commonly observed characteristics for that particular generation.

HotSpot Generations Memory in the Java HotSpot virtual machine is organized into three generations: a young generation, an old generation and a permanent generation.

Young generation

Space is usually small and likely to contain a lot of objects that are no longer referenced.

Young generation collections occur relatively frequently and are efficient and fast. Garbage collection algorithm chosen for a young generation should be time efficient.

The young generation consists of an area called Eden plus two smaller survivor spaces.

Most objects are initially allocated in Eden. The survivor spaces hold objects that have survived at least one young generation collection and have thus been given additional chances to die before being considered "old enough" to be promoted to the old generation.

Old generation

Objects that survive some number of young generation collections are eventually promoted, or tenured, to the old generation. This generation is typically larger than the young generation and its occupancy grows more slowly. As a result, old generation collections are infrequent, but take significantly longer to complete.

Garbage collection algorithm chosen for old generation should be space efficient.

Permanent Generation

The permanent generation is used to store meta-data of class and methods as well as the classes and methods themselves.

Once the data is in the permanent generation, the default behavior is that it remains there forever - this might vary between garbage collection policies.

Garbage Collection Types

When the young generation fills up, a young generation collection (a minor collection) of just that generation is performed. When the old or permanent generation fills up, a full collection (a major collection) is typically done. That is, all generations are collected.

Command line options

Garbage Collector Selection





Options for the Parallel and Parallel Compacting Collectors




Options for the CMS Collector




Heap and Generation Sizes

–Xmsn, –Xmxn, –XX:MaxPermSize=n

–XX:NewSize=n Default initial size of the new (young) generation

–XX:NewRatio=n Ratio between the young and old generations.

–XX:SurvivorRatio=n Ratio between each survivor space and Eden.

Garbage Collector Statistics





Java HotSpot Garbage Collection

The Garbage-First Garbage Collector

Java SE 6 Performance White Paper

Garbage Collection in Earlier versions

Post a Comment


Java (160) Lucene-Solr (112) Interview (64) All (58) J2SE (53) Algorithm (45) Soft Skills (39) Eclipse (33) Code Example (31) JavaScript (23) Linux (22) Spring (22) Windows (22) Tools (21) Web Development (20) Nutch2 (18) Bugs (17) Debug (16) Defects (14) Text Mining (14) Troubleshooting (14) J2EE (13) Network (13) PowerShell (11) Problem Solving (10) Chrome (9) Design (9) How to (9) Learning code (9) Performance (9) UIMA (9) html (9) Http Client (8) Maven (8) Security (8) Tips (8) bat (8) blogger (8) Big Data (7) Database (7) Google (7) Guava (7) JSON (7) Shell (7) System Design (7) ANT (6) Coding Skills (6) Lesson Learned (6) Programmer Skills (6) Scala (6) css (6) Algorithm Series (5) Cache (5) Continuous Integration (5) IDE (5) adsense (5) xml (5) AIX (4) Become a Better You (4) Code Quality (4) Concurrency (4) Dynamic Languages (4) GAE (4) Git (4) Good Programming Practices (4) Jackson (4) Memory Usage (4) Miscs (4) OpenNLP (4) Project Managment (4) Review (4) Spark (4) Testing (4) ads (4) regular-expression (4) Android (3) Apache Spark (3) Distributed (3) Eclipse RCP (3) English (3) Happy Hacking (3) IBM (3) J2SE Knowledge Series (3) JAX-RS (3) Jetty (3) Life (3) Python (3) Restful Web Service (3) Script (3) regex (3) seo (3) .Net (2) Android Studio (2) Apache (2) Apache Procrun (2) Architecture (2) Batch (2) Bit Operation (2) Build (2) Building Scalable Web Sites (2) C# (2) C/C++ (2) CSV (2) Career (2) Cassandra (2) Fiddler (2) Google Drive (2) Gson (2) How to Interview (2) Html Parser (2) Http (2) Image Tools (2) JQuery (2) Jersey (2) LDAP (2) Logging (2) Mac (2) Software Issues (2) Storage (2) Text Search (2) xml parser (2) AOP (1) Application Design (1) AspectJ (1) Chrome DevTools (1) Cloud (1) Codility (1) Data Mining (1) Data Structure (1) ExceptionUtils (1) Exif (1) Feature Request (1) FindBugs (1) Firefox (1) Greasemonkey (1) HTML5 (1) Httpd (1) I18N (1) IBM Java Thread Dump Analyzer (1) Invest (1) JDK Source Code (1) JDK8 (1) JMX (1) Lazy Developer (1) Machine Learning (1) Mobile (1) My Plan for 2010 (1) Netbeans (1) Notes (1) Operating System (1) Perl (1) Problems (1) Product Architecture (1) Programming Life (1) Quality (1) Redhat (1) Redis (1) RxJava (1) Solutions logs (1) Team Management (1) Thread Dump Analyzer (1) Visualization (1) boilerpipe (1) htm (1) ongoing (1) procrun (1) rss (1)

Popular Posts