By PATRICK PESCHLOW

The original address

Translation: Zhao Feng proofread: Xu Qiaohui

In the second part of this series, I’ll look at the different categories of parameters that HotSpot JVM provides. I’ll also discuss some interesting parameters for JIT compiler diagnostics.

JVM Parameter Classification

The HotSpot JVM provides three types of parameters. The first category contains standard parameters. As the name implies, the standard parameters, both functional and output, are fairly stable and likely to remain unchanged in future JVM releases. You can retrieve all the standard parameters using the Java command (or java-help). We saw some standard parameters in Part 1, such as -server.

The second type is the X parameter, which is not standardized and may change in future releases. All such arguments start with -x and can be retrieved using Java -x. Note that there is no guarantee that all parameters can be retrieved; there is no -xcomp.

The third category, which contains XX parameters (by far the most), is also not standard, or even listed for a long time. (Recently, this has changed, and we’ll discuss them in Part 3 of this series.) In practice, however, the X parameter is not different from the XX parameter. The functionality of the X parameter is fairly stable, however many of the XX parameters are still being experimented with (mainly by JVM developers for debugging and tuning implementations of the JVM itself). Value of HotSpot JVM documentation for non-standard parameters, which explicitly states that XX parameters should not be used without knowledge. This is true, and I think the same advice applies to the X parameter (as do some of the standard parameters). Regardless of the category, you should understand the impact of a parameter before using it.

Explain the syntax of the XX argument in one sentence. All XX arguments start with “-xx:”, but the syntax varies later, depending on the type of argument.

  • For Boolean arguments, we have “+” or “-” before setting the actual name of the JVM option. For example, -xx :+ is used to activate options, while -xx :- is used to unregister options.
  • For parameters that require a non-Boolean value, such as string or INTEGER, we write the name of the parameter first, followed by “=”, and then assign the value. For example, -xx := assigns a value.

Now let’s look at some of the XX parameters for JIT compilation.

-XX:+PrintCompilation and -XX:+CITime

When a Java application is running, it is very easy to see JIT compilation work. By setting -xx :+PrintCompilation, we can simply output some compilation of local code from bytecode. Let’s look at an example of a server VM running:

$ java -server -XX:+PrintCompilation Benchmark
  1       java.lang.String::hashCode (64 bytes) 2 java.lang.AbstractStringBuilder::stringSizeOfInt (21 bytes) 3 java.lang.Integer::getChars (131 bytes) 4 java.lang.Object::<init> (1 bytes) --- n java.lang.System::arraycopy (static) 5 java.util.HashMap::indexFor (6 bytes) 6 java.lang.Math::min (11 bytes) 7 java.lang.String::getChars (66 bytes) 8 java.lang.AbstractStringBuilder::append (60 bytes) 9 java.lang.String::<init> (72 bytes) 10 java.util.Arrays::copyOfRange (63 bytes) 11 java.lang.StringBuilder::append (8 bytes) 12 java.lang.AbstractStringBuilder::<init> (12 bytes) 13 java.lang.StringBuilder::toString (17 bytes) 14 java.lang.StringBuilder::<init> (18 bytes) 15 java.lang.StringBuilder::append (8 bytes) [...]  29 java.util.regex.Matcher::reset (83 bytes)Copy the code

Each time a method is compiled, a line -xx :+PrintCompilation is printed. Each line contains an ordinal number (a unique compile task ID) and the name and size of the compiled method. Therefore, the ordinal number 1 represents information about compiling hashCode methods in the String class into native code. Print additional information based on the method type and compilation task. For example, local wrapping methods will have an “n” argument in front of them, as in System:: ArrayCopy above. Note that such a method does not contain ordinals and method sizes, because it does not need to be compiled into native code. You can also see methods compiled repeatedly, such as StringBuilder:: Append with ordinals 11 and 15. The output stops at sequence number 29, indicating that a total of 29 methods need to be compiled at the Java application runtime.

There is no official documentation for -xx :+PrintCompilation, but this description is good for this parameter. I recommend going deeper.

The JIT compiler output helps us understand some of the differences between the client VM and the server VM. With the server VM, our application example outputs 29 lines, and with the client VM, we get 55 lines. This may seem odd, since the server VM should be doing “more” compilation than the client VM. However, due to their respective default Settings, the server VM looks at the method longer than the client VM to determine whether the method is hot and needs to be compiled. Therefore, it is not surprising that some of the potential methods are compiled later when using a server VM.

By setting -xx :+CITime separately, we can get various compilation statistics when the JVM shuts down. Let’s look at the statistics for a particular section:

$ java -server -XX:+CITime Benchmark [...]  Accumulated compilertimes (forcompiled methods only) ------------------------------------------------ Total compilation time : The Standard compilation: 0.0005s, Average: 0.004 On Stack replacement: 0.0005s, Average: 0.005 [...]Copy the code

A total of 0.178s was used (on 29 compilation tasks). These, “on stack replacement” takes 0.049 seconds, the time the compiled method is currently on the stack. This technique is not a simple implementation of performance display, in fact it is very important. Without “on stack replacement,” methods that take a long time to execute (for example, if they contain a long-running loop) will not be replaced by their compiled copy when they run.

Again, the comparison between the client VM and the server VM is interesting. The corresponding data from the client VM shows that even though 55 methods were compiled, these compilations took a total of only 0.021s. The server VM does less compilation but takes more time than the client VM. The reason for this is that more optimizations are performed when generating native code using the server VM.

In the first part of this series, we learned about the -xint and -xcomp parameters. Using a combination of -xx :+PrintCompilation and -xx :+CITime, we can get a better understanding of the behavior of the JIT compiler in both cases. Using -xint, -xx :+PrintCompilation produces 0 lines of output in both cases. Similarly, using -xx :+CITime verifies that no time has been spent compiling. Now switch to -xcomp, and the output is completely different. There are 726 lines of output when using the client VM, and then no more, because every relevant method is compiled. Using the server VM, we even got 993 lines of output, which tells us that more aggressive optimizations were performed. Similarly, the statistics printed when the JVM teardown show a huge difference between the two VMS. Consider the server VM running:

$ java -server -Xcomp -XX:+CITime Benchmark [...]  Accumulated compilertimes (forcompiled methods only) ------------------------------------------------ Total compilation time : Standard compilation: 1.567 s, Average: 0.002 On Stack replacement: 0.000 s, Average: -1#IO[...].Copy the code

Compiling with -xcomp took 1.567 seconds, which is 10 times more than using the default setting (that is, mixed mode). Again, applications run slower than those in mixed mode. By comparison, the client VM compiled 726 methods using -xcomp in 0.208s, even less than the server VM using -xcomp.

As a bonus, there is no “on stack replacement” happening here, because every method is compiled the first time it is called. The corrupted output “Average: -1.#IO” (correct :0) again shows that non-standard output parameters are not very reliable.

-XX:+UnlockExperimentalVMOptions

Sometimes when a particular JVM parameter is set, the JVM terminates after the output “Unrecognized VM Option”. If this happens, you should first check to see if you have entered the wrong parameter. However, if the parameter input is correct, and the JVM does not identify, you may need to set up – XX: + UnlockExperimentalVMOptions to unlock the parameters. I don’t know exactly what this security mechanism does, but I suspect that this parameter can have an impact on the stability of the JVM if used incorrectly (for example, they may overwrite some of the log files in the debug output).

Some parameters are only used during JVM development and are not actually used in Java applications. If a parameter is not – XX: + UnlockExperimentalVMOptions open, but you really need to use it, you can try to use the debug version of the JVM. For the Java 6 HotSpot JVM you can find it here.

-XX:+LogCompilation and -XX:+PrintOptoAssembly

If you find that using -xx :+PrintCompilation in a scene does not give you sufficient detail, you can use -xx :+LogCompilation to write the compilation output of the extension to the “hotspot.log” file. In addition to the many details of the compilation method, you can also see the tasks that the compiler thread starts. Note – XX: + LogCompilation need use – XX: + UnlockExperimentalVMOptions to unlock.

The JVM even allows us to see generation from bytecode compilation to native code. With -xx :+PrintOptoAssembly, the native code generated by the compiler thread is output and written to the “hotspot.log” file. Using this parameter requires the debug version of the server VM to be running. We can examine the output of -xx :+PrintOptoAssembly to see what optimizations the JVM actually performs, for example, regarding the elimination of dead code. A very interesting article provides an example.

More information about XX parameters

If this article piqued your interest, you can take a look at the XX parameters for HotSpot JVM for yourself. This is a good place to start.

JVM utility parameters (ii) Parameter classification and just-in-time (JIT) compiler diagnostics

Reprinted from: Simple Book – fold up low

Article: www.jianshu.com/p/6bd2317ae…