Tag Archives: JVM

JVM parameters You should Know

Here are some commonly used JVM parameters that every application developer should review, some may be appropriate for your application, some may not.

This post is a quick reference for these parameters, please refer to the official java docs for complete technical documentations.

-Xms -Xmx

e.g. -Xms16g -Xmx16g

The min and max of your heap size. When you set them the same, you fixed the size which helps avoid any change in real time, but of course you want to make sure you don’t waste the size. NOTE: If you use a big heap ( or are using large page size ( default is 4KB ), consider using -XX:+AlwaysPreTouch also.

When you set this, in your GC log you will start seeing entries like

  • Total time for which application threads were stopped: 0.0002480 seconds
  • Total time for which application threads were stopped: 0.0001090 seconds

It reports the duration of time when your application is paused due to any kind of GC activity, and is used as another meter to measure your application throughput of the system CPU.

It prints the GC in details in old gen, young gen and perm gen. Your gc log won’t be very useful without this.

It prints the timestamp of GC event, without this, the only timestamp would be the time since the application start.

This reports the tenuring statistics (how old the objects are) and the desired threshold of when objects will be promoted. This information gives you insight of how long your application may be holding on to objects.

-XX:NewSize -XX:MaxNewSize (or use -XX:NewRatio )
e.g. -XX:NewSize=4096m -XX:MaxNewSize=4096m

The min and max size of young gen. Alternatively, you can use NewRatio to specify the size of the young gen relative to the size of the entire heap. e.g. -XX:NewRatio=4 means 1GB will be designated as young gen in a 4GB heap (where old gen is about 3GB + perm gen).


e.g. -XX:SurvivorRatio=2

The young gen is comprised of eden space and 2 survivor spaces, the survivor ratio specifies the size of the survivor space relative to the eden space. e.g. if you have a 4GB young gen and survivor ratio is 2, then your eden space is 2GB and each of your survivor space has 1GB in size. In other words, your survivor space size = ( size of young gen / ( SurvivorRatio + 2 ) ). The ratio can be tuned for your application, the smaller the survivor space, the fewer iteration the objects can be tenured which could lead to more promotions.

Use the concurrent mark sweep garbage collector. This collector is responsible for collecting in old gen and will run in parallel to young gen parallel collector. Its IM ( initial mark ) and RM ( remark ) are the operations that will pause the application. Other times reported in the GC such as CS ( concurrent sweep ) are non-pausing so they won’t really affect your JVM as much as IM and RM.


e.g. -XX:CMSInitiatingOccupancyFraction=85

Assuming you already have UseConcMarkSweepGC, this tells the CMS (Concurrent Mark Sweep Collector) in the old gen to start collection process when old gen is 85% full, if it hasn’t already. Note that CMS could start before old gen reaches 85% even if you have already set the CMSInitiatingOccupancyFraction. CMS has its own logic to decide when to start. If you absolutely wants CMS to start only at 85%, then set also -XX:+UseCMSInitiatingOccupancyOnly. The default is 65%.


Consider using this when you have a big heap or are using large page. It pretouchs and set zero all the pages you have allocated during the initialization of your application. Normally a page is touched when it is used, but in the cases where you have big heap or big page size, this may increase your startup time, but is probably better than doing the pretouch in run time with performance impact.


This will allow CMS to also do some garbage collection in the permanent generation. If you use this option, be sure to also use UseConcMarkSweepGC. This has been seen to solve an apparent perm gen memory leak in Voltron: (described in this page: Perm Gen memory increases)


Leave a comment

Filed under JVM

ParallelRefProcEnabled Option in JVM

Some app uses weak references (say for caching, and it does not mind if JVM gabbage collects these cache lines to “effectively” increase the cache size), then GC spends a lot of time trying to figure which references can be cleaned up. Remark phase is single-threaded  by default unless this option “-XX:+ParallelRefProcEnabled”.

Leave a comment

Filed under JVM

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 – http://blog.ragozin.info/2012/10/safepoints-in-hotspot-jvm.html

link – www.cs.princeton.edu/picasso/mats/HotspotOverview.pdf

Leave a comment

Filed under JVM

JVM – Heap Dumps ( Generation and Analysis )

Looking at a heap dump is a great way of to ensure that your code is performing as you designed it. It also extremely useful for finding memory leaks.

The basic tools needed to generate a heap dump are available as part of the JDK or off the web. There are multiple analysis tools available either off the web or included in the JDK (starting with JDK 6).

click here – checkout my course on java and whitebox if you are interested. i cover JVM in details.

Generating a heap dump

The calls below fail to work on OS X. The following from Ken Sipeis claimed to fix it. (Thanks Chris)Let’s get to fixing the issue1. Download JSR-223’s engines https://scripting.dev.java.net/files/documents/4957/37593/jsr223-engines.zip
2. Download Rhino http://www.mozilla.org/rhino/download.html
3. Copy jsr223-engines/javascript/build/js-engine.jar to /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib/ext/
4. Copy rhino1_7R1/js.jar to /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib/ext/

  • you have to be sudo to do steps 3 and 4.

now jrunscript -q should look like this:
Language EmbeddedECMAScript 1.6 implemention “Mozilla Rhino” 1.6 release 2
Language AppleScript 2.0.1 implemention “AppleScriptEngine” 1.0
Language ECMAScript 1.6 implemention “Mozilla Rhino” 1.6R7

… and jrunscript will put you in a js shell.
… and jhat heap.out now works! Point your browser at http://localhost:7000 and object browse!

Also something I didn’t realize until I was preparing for this post… jmap worked for the console dump if I sudo’d the command. However it would not do a file dump. I did the file dump using jconsole and jmx. Now that the scripting issue is fixed, jmap is improved in the following manner:

1. if you type jmap , it now prompts you for your admin password (instead of just failing)
2. jmap -dump:live,format=b.file=heap.out 5510 now works

On Out Of Memory Error

You can instruct the JVM to generate a dump file whenever an OutOfMemory error is thrown. This is done by adding the following parameters to the command line.

-XX:+HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=<path to dump file>
Manual Heap Dump Generation JDK 5

You can use the jmap tool that comes with JDK 1.5 to generate a heap dump manually.

I was not able to get this to work on OS X.
jmap -heap:format=b -d64 <jvm pid>

This generates a file called heap.bin.

Manual Heap Dump Generation JDK 6

The jmap tool for JDK 6 has been upgraded and the options have changed.

I have not tried this to ensure the options are correct
jmap -J-d64 -dump:format=b,file=<path to dump file>  <jvm pid>

Heap Dump Analysis

There are several tools available to analyze heap dump files.

Heap Analysis Tool (HAT)

This easy to use tool is available as part of the JDK 6 installation as the command jhat. It is available for JDK 5 from https://hat.dev.java.net/. Launching the tools creates a web server on port 7000 that can be used to view the heap analysis.

I was not able to get either form to work on OS X.

JDK 5:

java -Xmx512m -jar ha26.jar <path to dump file>

JDK 6:

jhat <path to dump file>

Note : when generating heaps, it's almost always a good idea to use the :live option to only dump living objects. The times when you care about dead objects in the heap are few and far between.

<!– –>


Filed under Java, JVM