Five JVM command line flags you don't know

Ted neward, president of neward & Associates, wrote an exclusive Article for developerworks, "you don't know five ......" In the series, JVM is the heavy load machine behind Java functions and performance that most developers take for granted. However, few of us can understand how JVM works-like task allocation and garbage collection, turning threads, opening and closing files, interrupting and/or JIT compiling Java bytecode, and so on.

Unfamiliar with the JVM will not only affect the application performance, but it will also be difficult to try to fix problems in the JVM.

This article describes some command line flags that you can use to diagnose and tune the performance of your Java virtual machine.

1. disableexplicitgc

I can't remember how many times the user asked me to provide consultation on application performance issues. In fact, as long as the Cross-code operation quickly runs grep, the problem shown in Listing 1-original Java performance anti-pattern:

Listing 1. system. GC ();

 
 

  
  
      
  
  
// We just released a bunch of objects, so tell the stupid  
  
  
// garbage collector to collect them already!  
  
  
System.gc();  
 
 

Explicit garbage collection is a terrible idea-like locking you and a crazy bulldog in a phone booth. Although the called syntax depends on implementation, if your JVM is running a generational garbage collector (mostly) system. GC (); force the VM to execute "clean all" for a heap, although some are unnecessary. Cleaning all is several orders of magnitude more expensive than a conventional GC operation, which is just a simple mathematical problem.

Don't worry about me-sun engineers provide a JVM flag for this special manual error;-XX: + disableexplicitgc flag automatically transfers the system. GC () calls are converted into an empty operation, which provides you with the opportunity to run the code. GC () is harmful to the entire JVM execution.

2. heapdumponoutofmemoryerror

Have you ever experienced a situation where the JVM cannot be used and an outofmemoryerror is continuously thrown, and you cannot create a debugger for yourself to capture it or view any problems? Such occasional and/or uncertain problems often drive developers crazy.

Buyers are at your own risk

Not all VMS support all command line flags, except sun/Oracle VMS. The best way to identify if a flag is supported is to try it and see if it works properly. If these marks are not technically supported, you are solely responsible for using them. I, sun, Oracle, and IBM will be irresponsible if any of these marks makes your code, your data, your server, or everything disappear without a trace. We recommend that you first experiment in a virtual (very production) environment.

What you want at this moment is to capture a snapshot of the heap when the JVM disappears-XX: + heapdumponoutofmemoryerror command to complete this operation.

Run this command to notify the JVM to take a "heap dump snapshot" and save it in a file for processing. Generally, the jhat utility is used (I introduced it in the previous article ). You can use the-XX: heapdumppath flag to specify the actual path of the file to be saved. (No matter where the file is stored, make sure that the file system and/or Java Process must have the permission configuration and can be written in it .)

3. bootclasspath

It is helpful to regularly put a class into a class path, which is slightly different from the class path attached to the inventory JRE or the JRE class path that is extended in some way. (The New Java crypto API provider is an example ). If you want to extend the JRE, you must use the bootstrap classloader to customize the implementation. This Bootstrap can load java. Lang. Object and all related files in rt. jar.

Although you can illegally open Rt. jar and move your custom implementation or new data packets into it, technically you violate the protocol you agreed to when downloading JDK.

Instead, use the-xbootclasspath option of JVM and the skin-xbootclasspath/P and-xbootclasspath/.

-Xbootclasspath allows you to set the complete boot class path (This usually includes a pair of RT. jar), and some other JDK (not RT. JAR file. -Xbootclasspath/P: place the value in the existing bootclasspath and append-xbootclasspath/a to it.

For example, if you have modified java. Lang. Integer in the library and placed the modification in a sub-path named mod, the-xbootclasspath/amods parameter puts the new integer in front of the default parameter.

4. verbose

For virtual or any type of Java applications,-verbose is a useful first-level diagnostic application. The mark has three sub-signs: GC, class, and JNI.

Developers try to find out whether the JVM garbage collector is faulty or causes low performance. The first thing to do is to execute GC. Unfortunately, it is difficult to explain GC output-enough to write a book. Worse, the output printed in the command line may change in different Java versions or not in different JVM versions, which makes the correct interpretation more difficult.

Generally, if the garbage collector is a generational collector (most "enterprise-level" VMS ). A virtual flag will appear to indicate a full GC cleaning path; in Sun JVM, the flag will appear in the form of [fullgc...] at the beginning of the GC output line.

To diagnose classloader conflicts with/or non-matched classes, class can be of great help. It not only reports when the class is loaded, but also shows where the class is loaded, including the path to the jar (if it comes from the jar ).

JNI is rarely used, except when JNI or local library is used. When opened, it will report various JNI events, such as when the local library is loaded and when the method is bounced back. Once again, it is emphasized that the output will change in different JVM versions.

5. command-line-x

I listed my favorite command line options provided by JVM, but there are more to be found, run the command line parameter-X, list all non-standard (but mostly secure) parameters provided by JVM-for example:

-Xint: Run JVM in interpreted mode (this is useful for testing whether the JIT compiler actually works for your code or verifying whether there is a bug in the JIT compiler ).

-Xloggc:, does the same thing as-verbose: GC, but records a file without outputting it to the command line window.

JVM command line options often change, so regular viewing is a good idea. Even if you stare at the monitor late at night and go home at five o'clock P.M. and have dinner with your wife and children (or destroy your enemies in mass effect 2, depending on your preferences), they are all different.

Conclusion

In a production environment, the command line flag is not designed for permanent use-in fact, apart from the flag that you terminate to tune the JVM garbage collector, no non-standard command line mark is intended for production. However, as a tool, it is very useful to probe the internal work of virtual machines that are completely opaque in other aspects.

About the author

Ted neward, head of neward & Associates, is responsible for consulting, mentoring, training, and recommendations on Java,. net, XML services, and other platforms. He now lives near Seattle, WA.

From: http://developer.51cto.com/art/201010/229659.htm