7/26/2019 Inspecting HotSpot JVM Options

1/3

F r i d a y , J a n u a r y 7 , 2 0 1 1

Inspecting HotSpot JVM OptionsIntroduction

A method for inspecting the comprehensive set of HotSpot JVM options and some examples comparing differentoutputs.

Background

The Oracle JVM provides an enormous spectrum of options to control the runtime JVM. These options are given acriminally short and non-comprehensive discussion at the OTN here . OTN divides these options into three categories:Behavioural, Performance and Debugging. This is a useful abstraction but some examples Oracle gives in eachcategory can be misleading due to the overlap between Behavioural and Performance.

The JVM options themselves can be controlled in a number of ways: via the command line on JVM startup. via JMX for certain options where this is allowed. indirectly via the command line by a super-option which then sets other options.

automatically by the JVM. The JVM has ergonomic capability to detect features of the host and set optionsaccordingly.

Using the first two methods we are explicitly setting options ourselves and can easily track what value each optionhas ( true , false , 20 , 100 etc). These last two methods for setting options can cause developers the mostconfusion, as we have less insight and therefore less understanding over what options are being set. This puts us inan unfavourable position when explaining the runtime behaviour of our applications. To dump out every JVM optionand its value there is an option to do this hidden away in the JVM source code:

-XX:+PrintFlagsFinal

Usage

Let's see this in action! First let's run the following:

$ jdk1.6.0_23/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

(I have added -XX:+UnlockDiagnosticVMOptions as this unlocks more options for viewing and control. Also Ihave added -version at the end so Java doesn't complain that it has nothing to run and to supplement the results).

The sysout is quite large so I've saved it here . Firstly you may be surprised at the sheer quantity of JVM optionsavailable: 717! That's a lot of configuration! Before we dive into the options lets look at our host specification andthe output of the -version option. The host has 8 dual core 64bit AMD Opteron processors running at 3.2GHz so 16cores in total with 64GB of RAM. The Java -version output shows:

java version "1.6.0_23"Java(TM) SE Runtime Environment (build 1.6.0_23-b05)Java HotSpot(TM) Server VM (build 19.0-b09, mixed mode)

this tells us we are running Java 6 update 23 using the Server version of the HotSpot VM in 32bit mode. Now let's lookcloser at the output. For each option we can see the following columns:

1. Datatype. bool for booleans, uintx for unsigned integers etc2. Name3. Assignment. = means this is the default. := means this option was modified from the default valueby command line or ergonomics.4. Value5. Category. There are two large categories diagnostic or product . (I find this a better groupingthan Behavioural, Performance and Debugging.) and also manageable if this option can be set viaJMX. C1relates to the JIT compiler used in the Client JVM. C2 means the same but for the Server JVMand I suspect pd means Platform Dependent as most pd options are Solaris only.

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.htmlhttp://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.htmlhttp://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.htmlhttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlhttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlhttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlhttp://sites.google.com/site/zahid1705/redux/server.txthttp://sites.google.com/site/zahid1705/redux/server.txthttp://sites.google.com/site/zahid1705/redux/server.txthttp://sites.google.com/site/zahid1705/redux/server.txthttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlhttp://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html

7/26/2019 Inspecting HotSpot JVM Options

2/3

Let's look closer at the modified options which have the := assignment:

uintx InitialHeapSize := 67108864 {product}uintx MaxHeapSize := 1073741824 {product}uintx ParallelGCThreads := 13 {product}bool PrintFlagsFinal := true {product}bool UnlockDiagnosticVMOptions := true {diagnostic}bool UseParallelGC := true {product}

apart from the two flags which I set myself on the command line we can see Java ergonomics has given the heap asensible range of 64MB to 1GB. The fairly old Parallel Garbage Collector has been chosen with an enormous 13threads spawned to do the collection. Straightaway we've got a lot more insight into how our JVM is configured anda few ideas for improvements.

Client vs Server JVM Analysis

We know from looking at the -version output Java automatically chose the server JVM instead of the client JVM(Java automatically chooses server if it detects 64bit processors). But how do we know what options are setbecause Java chose the Server JVM? What options were set because of our host specification? Lets run the followingcommands and review the output:

$ jdk1.6.0_23/bin/java -client -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version $ jdk1.6.0_23/bin/java -server -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

I have saved the client output here and the diff client server here . Firstly lets look at the output from theClient JVM; it has 661 options, 56 fewer than the Server version. Now let's look solely at the Client options whichhave been modified, excluding the two options I set on the command line there are only two values which werechanged:

uintx InitialHeapSize := 16777216 {product}uintx MaxHeapSize := 268435456 {product}

so Java has chosen some fairly sensible values for the Client JVM: 16MB initial heap size with a max size of 256MB.There are many entries in the diff file mostly by virtue of the extra options available to the Server JVM or optionswhich relate to memory simply having higher values. Here are the more interesting differences:

< intx CICompilerCount = 1 {product}> intx CICompilerCount = 2 {product}< intx CompileThreshold = 1500 {pd product}> intx CompileThreshold = 10000 {pd product}

The Client VM waits only 1,500 invocations before compiling a method to native code and uses only one thread forcompilation vs the Server which waits for 10,000 invocations and uses two threads.

> bool DoEscapeAnalysis = true {C2 product}

In this build the Server VM has escape analysis enabled by default whereas the Client VM cannot enable escapeanalysis at all. I don't think this is sensible on Oracle's part as whilst escape analysis can improve performance forscientific computing (where many primitives are created within a method and then discarded once a final value hasbeen computed) for other applications escape analysis can lower performance when arguments do escape theirmethods and are better left on the heap. Slipping in such a change transparently can also be problematic asdevelopers upgrading to a new JVM may see performance degradation in their applications when no visiblecommand line option has changed. Developers should benchmark accordingly when upgrading JVM builds.

< bool RewriteBytecodes = false {pd product}< bool RewriteFrequentPairs = false {pd product}> bool RewriteBytecodes = true {pd product}> bool RewriteFrequentPairs = true {pd product}

An optimisation to rewrite two bytecode operations as one operation.

https://sites.google.com/site/zahid1705/redux/client.txthttps://sites.google.com/site/zahid1705/redux/client.txthttps://sites.google.com/site/zahid1705/redux/client.txthttps://sites.google.com/site/zahid1705/redux/diff-client-server.txthttps://sites.google.com/site/zahid1705/redux/diff-client-server.txthttps://sites.google.com/site/zahid1705/redux/diff-client-server.txthttps://sites.google.com/site/zahid1705/redux/diff-client-server.txthttps://sites.google.com/site/zahid1705/redux/client.txt

7/26/2019 Inspecting HotSpot JVM Options

3/3

Super Option Activation

As mentioned earlier some options are super-options and will enable other options. Let's take a look at a commonsuper option: -XX:+AggressiveOpts

The two commands are:

jdk1.6.0_23/bin/java -server -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -

version jdk1.6.0_23/bin/java -server -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

here are all the differences:

< bool AggressiveOpts = false {product}> bool AggressiveOpts := true {product}< intx AutoBoxCacheMax = 128 {C2 product}> intx AutoBoxCacheMax = 20000 {C2 product}< intx BiasedLockingStartupDelay = 4000 {product}> intx BiasedLockingStartupDelay = 500 {product}

< bool EliminateAutoBox = false {C2 diagnostic}> bool EliminateAutoBox = true {C2 diagnostic}< bool OptimizeFill = false {C2 product}> bool OptimizeFill = true {C2 product}< bool OptimizeStringConcat = false {C2 product}> bool OptimizeStringConcat = true {C2 product}

So a number of options have been enable and some others have been given more aggressive values. We know -XX:+AggressiveOpts changes with each JVM build. Let's look at an older build:

(NB. Java6u20 is the oldest build to support this form of option dumping)

jdk1.6.0_20/bin/java -server -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -

version jdk1.6.0_20/bin/java -server -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal

< bool AggressiveOpts = false {product}> bool AggressiveOpts := true {product}< intx AutoBoxCacheMax = 128 {C2 product}> intx AutoBoxCacheMax = 20000 {C2 product}< intx BiasedLockingStartupDelay = 4000 {product}> intx BiasedLockingStartupDelay = 500 {product}< bool DoEscapeAnalysis = false {C2 product}> bool DoEscapeAnalysis = true {C2 product}

< bool EliminateAutoBox = false {C2 diagnostic}> bool EliminateAutoBox = true {C2 diagnostic}< bool UseLoopPredicate = false {C2 product}> bool UseLoopPredicate = true {C2 product}

We can see in 6u20 DoEscapeAnalysis was an AggressiveOpt but in the new build6u23 DoEscapeAnalysis became the default (as did UseLoopPredicate ). Along the samelines OptimizeFill and OptimizeStringConcat may become default values in future builds.

Conclusion

There is enormous scope for coarse and fine grained control of JVM behaviour. The option -XX:+PrintFlagsFinal allows comprehensive reporting of the options and their values. The available optionsvary by build and JVM type (server or client). Recording and auditing this output is an important step in any Javabenchmarking or continuous monitoring exercise. Oracle can surreptitiously enable options in new Java buildswhich may cause inexplicable changes in performance and behaviour of existing applications.