Cross Column

Showing posts with label Hotspot VM Options. Show all posts
Showing posts with label Hotspot VM Options. Show all posts

Tuesday, June 5, 2012

What Are the Default HotSpot JVM Values?

Updated (09/16/2014):

In the latest JDK 8 releases, it only prints out product level options if you use, say, -XX:+PrintFlagsFinal.  To print other options, you could do something like this:
../bin/java -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions  
  -XX:+UnlockDiagnosticVMOptions -version

Oftentimes you will find the needs to understand better the options provided by Oracle's (formerly Sun's) HotSpot Java Virtual Machine.  For example, when you try to tune the performance of Java applications, you definitively want to know what JVM parameter values are chosen by default.  From the defaults, you might start fine-tuning their values based on your application's characteristics.

There are two JVM options which can be useful to you:
  • -XX:+PrintFlagsInitial 
  • -XX:+PrintFlagsFinal
At JVM startup, the system will print the initial/final JVM values used.  The values provided by PrintFlagsInitial are values set by default and the values printed for PrintFlagsFinal are final values chosen after the dynamic runtime changes are made based on your hardware environment.

-XX:+PrintFlagsFinal


For example, if  PrintFlagsFinal is specified, at the beginning of the WebLogic server log file, you can find:

starting weblogic with Java version:
java version "1.7.0_04-ea"
Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b17)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b18, mixed mode)
Starting WLS with line:
/export/home/bench/workload/target_jvm/jdk-hs/bin/java -server -Xms6400m -Xmx6400m -XX:+AggressiveOpts ...


[Global flags]

    uintx AdaptivePermSizeWeight                    = 20              {product}          
    uintx AdaptiveSizeDecrementScaleFactor          = 4               {product}          
    uintx AdaptiveSizeMajorGCDecayTimeScale         = 10              {product}          
    uintx AdaptiveSizePausePolicy                   = 0               {product}          

...
    uintx MinHeapFreeRatio                          = 0               {manageable}
    uintx MaxHeapFreeRatio                          = 100             {manageable}
     intx WorkAroundNPTLTimedWaitHang               = 1               {product}          
    uintx WorkStealingHardSpins                     = 4096            {experimental}     
     intx WorkStealingSleepMillis                   = 1               {experimental}     
    uintx WorkStealingSpinToYieldRatio              = 10              {experimental}     
    uintx WorkStealingYieldsBeforeSleep             = 5000            {experimental}     
    uintx YoungGenerationSizeIncrement              = 20              {product}          
    uintx YoungGenerationSizeSupplement             = 80              {product}          
    uintx YoungGenerationSizeSupplementDecay        = 8               {product}          
    uintx YoungPLABSize                             = 1024            {product}          
     bool ZeroTLAB                                  = false           {product}          
     intx hashCode                                  = 0               {product}           

In case you wonder what "x" means in the types intx and uintx, intx and uintx are the 'extended' int and 'extended' unsigned int types—They are 32bit wide on a 32-bit platform and 64bit wide on a 64bit platform.

Parameter Scope


The last value from the output specifies the scope of parameter, or when it can be used.  For example, if the value is
  • {experimental}
It means that you need to specify
  • -XX:+UnlockExperimentalVMOptions
to set the parameter.

Similarly, you can provide
  • -XX:+UnlockDiagnosticVMOptions
to enable the tuning of a parameter if the its scope is:
  • {C1 diagnostic} or
  • {C2 diagnostic}
C1 and C2 here relate to the JIT compiler used.  C1 is for the client VM while C2 is for the server's.

Finally,  if flags are marked as manageable, they are dynamically writeable through the JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. The manageable flags can also be set through jinfo -flag.

Test


We know the scope of  UseCriticalJavaThreadPriority parameter is experimental.  If we set it without specifying -XX:+UnlockExperimentalVMOptions first, here is the result:

$ /export/home/bench/workload/target_jvm/jdk-hs/bin/java -server -XX:+PrintFlagsFinal  
  -XX:+UseCriticalJavaThreadPriority -version >tmp.tmp
Unrecognized VM option 'UseCriticalJavaThreadPriority'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

However, if you add  -XX:+UnlockExperimentalVMOptions, you will be allowed to set its value :

$ /export/home/bench/workload/target_jvm/jdk-hs/bin/java -server -XX:+PrintFlagsFinal 
  -XX:+UnlockExperimentalVMOptions -XX:+UseCriticalJavaThreadPriority -version >tmp.tmp
java version "1.7.0_04-ea"
Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b17)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b18, mixed mode)

Finally, remember to add -version at the end as shown here:

$jdk-hs/bin/java -server -XX:+PrintFlagsFinal -XX:+UseSerialGC -version >tmp5.txt

For example, if you specified options in this order, it would ignore -XX:+UseSerialGC setting:

$jdk-hs/bin/java -server -XX:+PrintFlagsFinal -version -XX:+UseSerialGC >tmp6.txt

 

How about JRockit?


For JRockit, you use:
  •  ./java -Xprintflags -version

 

Notes

  • {pd product} means platform dependent

 

References

  1. HotSpot JVM Options Displayed: -XX:+PrintFlagsInitial and -XX:+PrintFlagsFinal
  2. Inspecting HotSpot JVM Options
  3. Redux: Inspecting HotSpot JVM Options
  4. Oracle® JRockit Command-Line Reference Release R28
  5. Default Values of JRockit's VM Options (XML and More)
  6. HotSpot Glossary of Terms

Thursday, March 29, 2012

Understanding Garbage Collector Output of Hotspot VM

If garbage collection becomes a bottleneck, you will most likely have to customize the total heap size as well as the sizes of the individual generations. Before any tuning, you need to check the verbose garbage collector output and then explore the sensitivity of your individual performance metric to the garbage collector parameters.

In this article, we are going to examine the verbose output of garbage collector from Hotspot VM.  For all the needed background, please read [1-6].

Hotspot VM Options

Our test case used the following space-related settings:
  • -server -XX:+UseParallelGC  -Xms2048m -Xmx2048m -XX:PermSize=384m -XX:MaxPermSize=384m  -XX:SurvivorRatio=10
The command line option -verbose:gc causes information about the heap and garbage collection to be printed at each collection.  Our test case included the following report-related settings:
  • -Xloggc:/<path-to-output>/gc_0.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC 
Note that there is little additional overhead in the HotSpot VM to report garbage collection data. In fact, the overhead is so small it is recommended to collect garbage collection data in production environments[7].

Analysis of Heap Spaces

At the bottom of gc_0.log file, you can find the following heap information:

Heap
 PSYoungGen      total 642048K, used 511911K [0x00000007d5400000, 0x0000000800000000, 0x0000000800000000)
  eden space 583680K, 81% used [0x00000007d5400000,0x00000007f2737e78,0x00000007f8e00000)
  from space 58368K, 57% used [0x00000007f8e00000,0x00000007faeb1ed0,0x00000007fc700000)
  to   space 58368K, 0% used [0x00000007fc700000,0x00000007fc700000,0x0000000800000000)
 ParOldGen       total 1398784K, used 728598K [0x000000077fe00000, 0x00000007d5400000, 0x00000007d5400000)
  object space 1398784K, 52% used [0x000000077fe00000,0x00000007ac585ad0,0x00000007d5400000)
 PSPermGen       total 393216K, used 229261K [0x0000000767e00000, 0x000000077fe00000, 0x000000077fe00000)
  object space 393216K, 58% used [0x0000000767e00000,0x0000000775de3728,0x000000077fe00000)
Because of our heap size settings:
  • -Xms2048m -Xmx2048m
the total heap space should be 2048MB which is confirmed from the output:

  Heap Total = PSYoungGen Total + ParOldGen Total
           = 642048K + 1398784K
           = 2048M

Our settings for Permanent Generation are:
  • -XX:PermSize=384m -XX:MaxPermSize=384m
which is confirmed from the output:
  PSPermGen       total 393216K

Finally, we have set the survivor ratio to be 10, this is also confirmed by the output:

  eden space /from space =  583680K/58368K = 10
Note that survivor space consists of two ping-pong buffers (i.e., from space and to space).

Full Garbage Collection

In the HotSpot VM, the default behavior on a full garbage collection is to garbage collect the young generation, old generation, and permanent generation spaces. In addition, the old generation and permanent generation spaces are compacted along with any live objects in young generation space being promoted to the old generation space. Hence, at the end of a full garbage collection, young generation space is empty, and old generation and permanent generation spaces are compacted and hold only live objects.

828.560: [Full GC828.930:
  [SoftReference, 0 refs, 0.0000060 secs]828.930:
  [WeakReference, 30056 refs, 0.0048320 secs]828.935:
  [FinalReference, 4333 refs, 0.0400380 secs]828.975:
  [PhantomReference, 28 refs, 0.0000130 secs]828.975:
  [JNI Weak Reference, 0.0000090 secs]
  [PSYoungGen: 41219K->0K(651136K)]
  [ParOldGen: 1360914K->639030K(1398784K)]
  1402134K->639030K(2049920K)
  [PSPermGen: 228218K->226531K(393216K)], 2.6372320 secs]
  [Times: user=12.85 sys=0.07, real=2.64 secs]

There are three pieces of GC information in GC output line:
  • Time
  • Buffer Size
  • Count
All Full GC output lines are timestamped.  For example, numbers like 828.560 and 828.930 are elapsed time in seconds since server started.  There are also three measurement times (i.e., user, system and real ) at the end of line.  User time (i.e., 12.85) is total user CPU time used by the garbage collector which includes all GC task threads (note that we have eight GC task threads in our case).  System time (i.e., 0.07) is the CPU time used by the operating system on behalf of the garbage collector.  Real time (i.e., 2.64 secs) is the wall clock time or elapsed time used by the garbage collector. 

To look at space reclaimed after a Full GC, we will use Old Generation space as an example.  The numbers before and after the arrow (e.g., 1360914K->639030K from the ParOldGen section) indicate the combined size of live objects before and after garbage collection, respectively. The next number in parentheses (e.g., (1398784K) ) is the committed size of the Old Generation space.

As for the counts, it requires no explanation.  They are reference counts of objects in different categories: softly referenced, weakly referenced, etc.

Minor Garbage Collection

A minor GC collects the young generation space.  The young generation is divided into 3 spaces:
  • Eden-space
  • From-space
  • To-space
After a minor collection completes, both eden and the from-survivor space are empty. However, these details are not shown in the following sample output line from a Minor GC.

828.465: [GC828.543:
  [SoftReference, 0 refs, 0.0000060 secs]828.543:
  [WeakReference, 5399 refs, 0.0008020 secs]828.544:
  [FinalReference, 1366 refs, 0.0079250 secs]828.552:
  [PhantomReference, 0 refs, 0.0000050 secs]828.552:
  [JNI Weak Reference, 0.0000030 secs]
  [PSYoungGen: 646557K->41219K(651136K)]
  1974687K->1402134K(2049920K), 0.0947580 secs]
  [Times: user=0.53 sys=0.02, real=0.09 secs] 

Final Words

The heap size settings (including -XX:SurvivorRatio=10) we have chosen here turned out to be a bad choice.  So, don't just copy and paste for your own environment.

Finally, to tune for throughput or latency, you tend to set:
  • both -Xms and -Xmx to the same value (as done in our case)
  • -Xmn should be used only when -Xms and -Xmx are set to the same value.

References

  1. Java HotSpot VM Options
  2. The most complete list of -XX options for Java 6 JVM
  3. Understanding Garbage Collection
  4. Diagnosing Java.lang.OutOfMemoryError 
  5. Diagnosing a Garbage Collection problem 
  6. Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning 
  7. Java Performance by Charlie Hunt and Binu John 
  8. Java Tuning White Paper 
  9. Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine

© Travel for Life Guide. All Rights Reserved.

Analytical Insights on Health, Culture, and Security.