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

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

What Are the Default HotSpot JVM Values