Java Garbage Collection Notes

Ergonomics :

A feature referred to here as ergonomics was introduced in J2SE 5.0. The goal of ergonomics is to provide good performance with little or no tuning of command line options by selecting the

  • garbage collector,
  • heap size,
  • and runtime compiler

Generational Collection : Young and tenure Gen

Collectors in Young Gen :

minor collections :

serial collectors – applications with small data set and single processors

throughput collectors – Applications that have medium to large data sets.

Generational Collection

Generations in Heap / Garbage collection : 

Yong Generation :

Tenured Generation :

 Permanent Generation :

A third generation closely related to the tenured generation is the permanent generation which holds data needed by the virtual machine to describe objects that do not have an equivalence at the Java language level. For example objects describing classes and methods are stored in the permanent generation.

Performance Considerations for Garbage Collection :

  1. Throughput is the percentage of total time not spent in garbage collection, considered over long periods of time. Throughput includes time spent in allocation (but tuning for speed of allocation is generally not needed).throughput is inversely proportional to the amount of memory available. Total available memory is the most important factor affecting garbage collection performance.
  2. Pauses are the times when an application appears unresponsive because garbage collection is occurring.
  3. Memory Footprint 
  4. Promptness is the time between when an object becomes dead and when the memory becomes available

some examples / scenarios :

Large Yong Generation (size) –  maximize throughput – at the expense of higher footprint, promptness and pause times.

Anatomy of GC log :

[GC 325407K->83000K(776768K), 0.2300771 secs] 

GC – Minor GC

325407K->83000K – size of live objects before and after garbage collection, respectively. After minor collections the size includes some objects that are garbage (no longer alive) but that cannot be reclaimed.  These objects are either contained in the tenured generation, or referenced from the tenured or permanent generations.

(776768K) – the amount of space usable for java objects without requesting more memory from the operating system. ( excludes space allocated to one of the survivor spaces and permanent gen )

The option -XX:+PrintGCDetails

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs] 

[DefNew: 64575K->959K(64576K), 0.0457646 secs] – indicates space revovered by minor collection in young Gen and available space in Yong Gen ( not it was only minor collection which was invoked during this cycle )

196016K->133633K(261184K) – indicates the overall space made available in the heap. and corresponding total time ( this is time taken by young gen minor collection plus some overhead )

The option -XX:+PrintGCTimeStamps will add a time stamp at the start of each collection. This is useful to see how frequently garbage collections occur.

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]

111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

Sizing Generations : 

-Xms – Committed Space , this is space is allocated at the initialization of JVM

Difference between -Xmx and -Xms – is the virtual space  ( Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice. )

MinHeapFreeRatio and  MaxHeapFreeRatio – These two ratios help in shrinking and expanding the heap size across the generations within the bounds of Xms and Xmx based on the ratio. For example if MinHeapFreeRatio is set to 40 (or 40%) , the generation will be expanded to maintain 40% free space as the heap is filled up.

NewRatio – XX:NewRatio=3 means that the ratio between the young and tenured generation is 1:3. In other words, the combined size of the eden and survivor spaces will be one fourth of the total heap size. ( Note : Increase the young generation size as you increase the number of processors, since allocation can be parallelized.)

SurvivorRatio – can be used to tune the size of the survivor spaces, but this is often not as important for performance. For example, -XX:SurvivorRatio=6 sets the ratio between eden and a survivor space to 1:6. In other words, each survivor space will be one sixth the size of eden, and thus one eighth the size of the young generation (not one seventh, because there are two survivor spaces).


Concepts in GC : 

Safe-point : 

App Stops : 

The only non-GC case that I know of that brings threads to a safepoint is JIT-related (replacing compiled code with interpreted)[1]. One question that I would have would be if this was application-specific thing or if we see the safepoint issues elsewhere, in which case we might be able to ignore them. 33 minutes seems like it’s a long time in to be doing any deoptimization, unless there was a lot of dynamic codegen going on (in which case, stop doing that since it’s slow). That seems unlikely as well, since while the server compiler is more aggressive, it’s not so aggressive that it would be willing to deoptimize that frequently (I’d expect it to keep things in interpreted mode rather than compile if it was doing it that often).

link –

link –


Leave a comment

Filed under JVM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s