About Richard Warburton

Richard is a Principle Software Engineer at jClarity, interested in deep dive performance issues and compiler verification, Adopt-aJSR, Adopt OpenJDK and the LJC. He holds a PhD from the University of Warwick and lives in London.

Garbage Collection in Java (2)

Parallel Scavenge

Today we cover how Parallel GC works. Specifically this is the combination of running a Parallel Scavenge collector over Eden and the Parallel Mark and Sweep collector over the Tenured generation. You can get this option by passing in -XX:+UseParallelOldGC though its the default on certain machine types.

You may want to read my first blog post on Garbage Collection if you haven’t since this gives a general overview.
 
 

Eden and Survivor Spaces

In the parallel scavenge collector eden and survivor spaces are collected using an approach known as Hemispheric GC. Objects are initially allocated in Eden, once Eden is close to full 1 a gc of the Eden space is triggered. This identifies live objects and copies them to the active Survivor Space2. It then treats the whole Eden space as a free, contiguous, block of memory which it can allocate into again.

In this case the allocation process ends up being like cutting a piece of cheddar. Each chunk gets sliced off contiguously and then the slice next to is the next to be ‘eaten’. This has the upside that allocation merely requires pointer addition.

A slab of cheddar, ready to be allocated.

A slab of cheddar, ready to be allocated.

In order to identify live objects a search of the object graph is undertaken. The search starts from a set of ‘root’ objects which are objects that are guaranteed to be live, for example every thread is a root object. The search then find objects which are pointed to by the root set, and expands outwards until it has found all live objects. Here’s a really nice pictorial representation, courtesy of Michael Triana

heap-roots

Parallel in the context of parallel scavenge means the collection is done by multiple threads running at the same time. This shouldn’t be confused with incremental GC, where the collector runs at the same time as, or interleaved with, the program. Parallel collection improves overall GC throughput by better using modern multicore CPUs. The parallelism is achieved by giving each thread a set of the roots to mark and a segment of the table of objects.

There are two survivor spaces, but only one of them is active at any point in time. They are collected in the same way as eden. The idea is that objects get copied into the active survivor space when they are promoted from eden. Then when its time to evacuate the space they are copied into the inactive survivor space. Once the active survivor space is completely evacuated the inactive space becomes active, and the active space becomes inactive. This is achieve by flipping the pointer to the beginning of the survivor space and means that all the dead objects in the survivor space can be freed at the cost of assigning to a single pointer.

Young Gen design and time tradeoffs

Since this involves only copying live objects and pointer changes the time taken to collect eden and survivor spaces is proportional to the amount of live objects. This is quite important since due to the generational hypothesis we know that most objects die young, and there’s consequently no GC cost to freeing the memory associated with them.

The design of the survivor spaces is motivated by the idea that collecting objects when they are young is cheaper than doing a collection of the tenured space. Having objects continue to be collected in a hemispheric fashion for a few GC runs is helpful to the overall throughput.

Finally the fact that eden is organised into a single contiguous space makes object allocation cheap. A C program might back onto the ‘malloc’ command in order to allocate a block of memory, which involves traversing a list of free spaces in memory trying to find something that’s big enough. When you use an arena allocator and consecutively allocate all you need to do is check there is enough free space and then increment a pointer by the size of the object.

Parallel Mark and Sweep

Objects that have survived a certain number of collections make their way into the tenured space. The number of times that they need to survive is referred to as the ‘tenuring threshold’. Tenured Collections work somewhat differently to Eden, using an algorithm called mark and sweep. Each object has a mark bit associated with it. The marks are initially all set to false and as the object is reached during the graph search they’re set to true.

The graph search that identifies live objects is similar to the search described for young generation. The difference is that instead of copying live objects, it simply marks them. After this it can go through the object table and free any object that isn’t live. This process is done in parallel by several threads, each search a region of the heap.

Unfortunately this process of deleting objects that aren’t live leaves the tenured space looking like Swiss Cheese. You get some used memory where objects live, and gaps in between where objects used to live. This kind of fragmentation isn’t helpful for application performance because it makes it impossible to allocate objects that are bigger than the size of the holes.

Cheese after Mark and Sweep.

Cheese after Mark and Sweep.

In order to reduce the Swiss Cheese problem the Parallel Mark/Sweep compacts the heap down to try and make live objects contiguously allocated at the start of the tenured space. After deletion it search areas of the tenured space in order to identify which have low occupancy and which have high occupancy. The live objects from lower occupancy regions are moved down towards regions that have higher occupancy. These are naturally at the lower end of memory from the previous compacting phase. The moving of objects in this phase is actually performed by the thread allocated to the destination region, rather than the source region.

Low occupancy cheese.

Low occupancy cheese.

Summary

  • Parallel Scavenge splits heap up into 4 Spaces: eden, two survivor spaces and tenured.
  • Parallel Scavenge uses a parallel, copying collector to collector Eden and Survivor Spaces.
  • A different algorithm is used for the tenured space. This marks all live objects, deletes the dead objects and then compacts the space/
  • Parallel Scavenge has good throughput but it pauses the whole program when it runs.

In part three I’ll look at how the CMS, or Concurrent-Mark-Sweep, collector works. Hopefully this post will be easier for those with dairy allergies to read.

  1. Technically there is an ‘occupancy threshold’ for each heap space – which defines how full the space is allowed to get before collection occurs.
  2. This copying algorithm is based on Cheney’s algorithm.
Reference: Garbage Collection in Java (2) from our JCG partner Richard Warburton at the Insightful Logic blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

3 Responses to "Garbage Collection in Java (2)"

  1. Maddy says:

    Garbage collection with parallel collector is much faster that serial collector. As you know today almost all Java applications run on machines with a lot of physical memory and multiple CPUs. The parallel collector, also known as the throughput collector, was developed in order to take advantage of available CPUs rather than leaving most of CPU processes idle. Therefore throughput of parallel collector is much better than serial collector. If you are not aware about garbage collection fundamentals and object generations, then I will recommend you to first read my blog

    To Read More Click Here

    http://www.somanyword.com/2014/01/parallel-garbage-collector-in-java/

  2. Maddy says:

    Garbage collection with parallel collector is much faster that serial collector. As you know today almost all Java applications run on machines with a lot of physical memory and multiple CPUs. The parallel collector, also known as the throughput collector, was developed in order to take advantage of available CPUs rather than leaving most of CPU processes idle. Therefore throughput of parallel collector is much better than serial collector.

    To Read More Click Here

    http://www.somanyword.com/2014/01/parallel-garbage-collector-in-java/

  3. Binh Thanh Nguyen says:

    Thanks, nice post

Leave a Reply


5 − = two



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close