This article is based on Java 6 (update 21oder 21), and HotSpot JVM provides two new parameters that can be printed on the command line after JVM startup with all XX parameters and values.

-XX:+PrintFlagsFinal and -XX:+PrintFlagsInitial
Copy the code

Let’s look at the output of the new parameter now. -xx :+PrintFlagsFinal with -client results in an alphabetical table of 590 arguments (note that the number of arguments varies from release to release)

$ java -client -XX:+PrintFlagsFinal Benchmark [Global flags] uintx AdaptivePermSizeWeight = 20 {product} uintx AdaptiveSizeDecrementScaleFactor = 4 {product} uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product} uintx AdaptiveSizePausePolicy = 0 {product} [...]  uintx YoungGenerationSizeSupplementDecay = 8 {product} uintx YoungPLABSize = 4096 {product} bool ZeroTLAB = false {product} intx hashCode = 0 {product}Copy the code

(Proofreading note: You can try to enter the above command from the command line to implement it yourself)

Each row of the table contains five columns to represent an XX parameter. The first column represents the data type of the parameter, the second column is the name, the fourth column is the value, and the fifth column is the category of the parameter. The third column “=” indicates that the fourth column is the default value for the parameter, while “:=” indicates that the parameter has been assigned by the user or JVM.

Note that I only use the Benchmark class for this example, because the previous chapters in this series used the same class. You can get the same output even without a main class by running Java with the additional argument -version. Now let’s examine how many parameters the Server VM provides. We can also specify parameters – XX: + UnlockExperimentalVMOptions and – XX: + UnlockDiagnosticVMOptions; To unlock any additional hidden parameters.

$ java -server -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal Benchmark
Copy the code

724 parameters. Let’s take a look at the parameters that have been assigned.

$ java -server -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal Benchmark | grep ":"  uintx InitialHeapSize := 57505088 {product} uintx MaxHeapSize := 920649728 {product} uintx ParallelGCThreads := 4 {product} bool PrintFlagsFinal := true {product} bool UseParallelGC := true {product}Copy the code

(Proofread: this command is useful.) We just set our own argument -xx :+PrintFlagsFinal. Other parameters are set by the Server VM based on the system to run with the appropriate heap size and GC Settings.

If we just want to see the default values for all XX arguments, we can use a related argument, -xx :+PrintFlagsInitial. Using -xx :+PrintFlagsInitial only shows the data in the third column of “=” (and also those parameters with other values set).

Note, however, that some of the arguments are lost when compared with -xx :+PrintFlagsFinal, presumably because they were created dynamically.

It is interesting to examine the contents of the table, and by comparing the behavior of the client and Server VMS, it is obvious which parameters affect the other parameters. For those interested, check out this great article on Inspecting HotSpot JVM Options. This article mainly explains the parameter categories in the fifth column.

-XX:+PrintCommandLineFlags

Let’s look at another argument, which is actually quite useful: -xx :+PrintCommandLineFlags. This parameter lets the JVM print out the names and values of the detailed XX parameters that have been set by the user or JVM.

In other words, it enumerates the result of -xx :+PrintFlagsFinal with a “:=” argument in the third column. In this way, we can use -xx :+PrintCommandLineFlags as a shortcut to view the modified parameters. Look at the following example.

$ java -server -XX:+PrintCommandLineFlags Benchmark

 -XX:InitialHeapSize=57505088 -XX:MaxHeapSize=920081408 -XX:ParallelGCThreads=4 -XX:+PrintCommandLineFlags -XX:+UseParallelGC
Copy the code

Now if we set -xx :+PrintCommandLineFlags every time we start the Java program and print it to a log file, this will record the impact of the JVM parameters we set on the application’s performance. Similar to -showversion(see Part1), I recommend that the -xx :+PrintCommandLineFlags parameter should always be set in the JVM startup configuration items. Because you never know when you’re going to need it.

Oddly enough, in this example, listing the maximum value of the heap with -xx :+PrintCommandLineFlags is a bit smaller than listing the corresponding value with -xx :+PrintFlagsFinal. If anyone knows the reason for the difference, please let me know.

That’s it! Stay tuned for more next time!