Advanced JVM Tuning for Low Pause

The standard Java Virtual Machine (JVM) is configured to optimize for throughput. But some systems are more interested in low pause/reduced latency and GC (garbage collection) might be one source of pausing. (you can read an interesting article about what latency means to your business)

I have found a post on GigaSpaces forum providing some possible JVM configurations to optimize on latency:

-Xms2g -Xmx2g -Xmn150m 
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 
-XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=10 
-XX:CMSIncrementalDutyCycle=50 -XX:ParallelGCThreads=8 
-XX:+UseParNewGC -XX:MaxGCPauseMillis=2000 
-XX:GCTimeRatio=10 -XX:+DisableExplicitGC

Please note that -XX:+UseConcMarkSweepGC has the heaviest impact on performance – decrease of 40%.

The following set of parameters shows 20% better performance than with -XX:+UseConcMarkSweepGC while the pause size still is below 100msec in embedded test with payload 10KB and 100 threads:

-Xms2g -Xmx2g -Xmn150m 
-XX:GCTimeRatio=2 -XX:ParallelGCThreads=8 
-XX:+UseParNewGC -XX:MaxGCPauseMillis=2000 
-XX:+DisableExplicitGC

While I’m pretty sure that most of the applications do no need such an advanced VM configuration, it is interesting to see what strategies are employed when low latency is needed.

Option	Details
-XX:+UseConcMarkSweepGC	Sets the garbage collector policy to the concurrent (low pause time) garbage collector (also known as CMS)
-XX:+CMSIncrementalMode	Enables the incremental mode. (works only with -XX:+UseConcMarkSweepGC)
-XX:+CMSIncrementalPacing	Enables automatic adjustment of the incremental mode duty cycle based on statistics collected while the JVM is running
-XX:CMSIncrementalDutyCycleMin	The percentage (0-100) which is the lower bound on the duty cycle when CMSIncrementalPacing is enabled
-XX:CMSIncrementalDutyCycle	The percentage (0-100) of time between minor collections that the concurrent collector is allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value.
-XX:ParallelGCThreads	Sets the number of garbage collector threads
-XX:+UseParNewGC	Enables multi threaded young generation collection.
-XX:MaxGCPauseMillis	A hint to the throughput collector that it’s desirable that the maximum pause time is lowed than the given value. (n.b. it looks like this value can also be used with the CMS garbage collector)
-XX:GCTimeRatio	A hint to the virtual machine that it’s desirable that not more than 1 / (1 + GCTimeRation) of the application execution time be spent in the collector
-XX:+DisableExplicitGC	Disables explicit garbage collection calls (System.gc())

There is no need to learn all these flags by heart as you can find them covered in various documents:

• Tuning Garbage Collection
• Java Tuning White Paper
• Garbage Collector Ergonomics
• JVM 1.4.2

If you still need help you can try asking for help on the General Performance Forum.

Advertisement

Type resolution in JVM specification

The JVM spec covers the following details about the lifecycle of a program:

• VM start up
• class and interface loading
• linking
• initialization
• creation of new class instances
• unloading of classes
• VM exit

In this entry, we are interested in detailing how JVM is handling type resolution. Having the following code:

public class EntryPoint {
 public void someMethod() {
   ExternalDependecyClass.callMethod();
 }
}

import not.on.classpath.SomeClass

public class ExternalDependencyClass {
 public static void callMethod() {
   SomeClass cls= new SomeClass();
   // [...] work
 }
}

We are interested in finding out if the spec describes the behavior of the above code when the SomeClass is not found on the classpath (though the compilation was correctly performed).

So, the class EntryPoint is loaded, and it must be initialized before it can be invoked, and a type (class or interface) must always be linked before it is initialized.

Linking step involves:

• verification: checks if the loaded representation is well formed, has a proper symbol table, the bytecode obeys the semantic requiremetns of the JVM
• preparation: involves allocation of static storage and any data structures that are used internally by the virtual machine, such as method tables.
• resolution (optional)

Resolution is the process of checking symbolic references from the loaded class to other classes and interfaces, by loading the other classes and interfaces that are mentioned and checking that the references are correct.

The resolution step is optional at the time of initial linkage.

An implementation may resolve a symbolic reference from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors from further loading and linking steps.)

This is an eager or static resolution implementation. There is also possible to do the resolution in a lazy way:

An implementation may instead choose to resolve a symbolic reference only when it is actually used; […]. In this case, if the class had several symbolic references to another class, the references might be resolved one at a time or perhaps not at all, if these references were never used during execution of the program.

If the JVM implementation has chosen to use the eager/static type resolution strategy than an exception will be thrown before the program is executed. For the “lazy” type resolution JVMs, an exception will be thrown if and only if the symbolic reference is used.

Now, you may wonder what is the solution. The only approach that will work in any JVM disregarding how the JVM implements the type resolution is to load the classes containing unsatisfied dependencies at the moment the execution needs them through reflection (for example if you are developing a library/framework than you will always have to do it this way because you don’t know on what JVMs the library will be used). But, if you are developing an application that is known to run only on a JVM that used the “lazy” type resolution strategy than the initial code is safe.

As a final note, SUN JVMs (at least 1.4 and 1.5) are using the lazy type resolution strategy.

Reference:
• Loading, Linking, and Initializing

category: JVM