|
|
One major benefit of the Oracle JRockit JVM is that it is a Just-In-Time (JIT) compiling JVM (see How the JRockit JVM Compiles Code for information on how code is compiled), meaning the first time the JVM runs a method it is compiled into machine code. The JVM compiles all the classes to native code the first time they are called. This slows down the application run at startup when a lot of new methods are compiled, but in return the methods will run fast already the second time they’re invoked. The methods most often run will later be recompiled by the JRockit JVM and therefore optimized further for the following runs, ensuring that your application runs even faster.
This section describes how you can recognize and troubleshoot a slow-starting JVM. It includes information on the following subjects:
There are several possible causes for your application to seem slow in the beginning.
If you’ve recently switched from another JVM to the JRockit JVM, you might think the JVM is starting too slowly. This is particularly noteworthy if you’ve switched to the JRockit JVM as your production JVM from a third-party development JVM. Actually, what might appear to be a slow start is normal operation. The JRockit JVM is designed for use with long-running applications. As such, you should expect longer start-up times as code is compiled and optimized. The JVM is not starting slow, it just has more information to process during startup. Once all of the methods are compiled, the JVM should run much faster.
To see if your application compiles a lot of methods in the beginning of the run, you can start it with the option -Xverbose:codegen.
With this option set, the following information will be shown about the method that is being compiled: name, memory location, duration of the compilation, and the amount of time that has passed since the compilation started. See Listing 26-1 for an example of a -Xverbose:codegen print out.
[codegen] #775 1 (0x2) n jrockit/memory/AtomicInt.<init>(I)V
[codegen] #775 1 (0x2) n @0x7D62ED90-0x7D62ED9C 0.09 ms (277.99 ms)
[codegen] #776 1 (0x2) n jrockit/memory/AtomicInt.set(I)V
[codegen] #776 1 (0x2) n @0x7D62EDA0-0x7D62EDAA 0.08 ms (278.06 ms)
Conversely, if you have a lot of methods that need to be compiled during startup, you will have a fairly long startup time compared to if you would have few.
Once the JIT compilation is complete, the compiled methods will no longer need as much time to run; however, the JRockit JVM continuously optimizes frequently-used methods during the application run which, at times, can give the appearance of the JVM running slowly.
The startup time can also be extended if you have an application that is searching for a certain file, for example, a data file. If you suspect that your application is causing the slow start, create a JRA recording and analyze the application data in the JRockit Runtime Analyzer. This tool is included in Oracle JRockit Mission Control.
If you are running the JRockit JVM R27.1 or later with JRockit Mission Control 2.0 or later, complete instructions for creating and interpreting a JRA recording are available from the Oracle JRockit Mission Control online help.
To measure timing inside your application you can use the methods System.nanoTime() and System.currentTimeMillis() in your application. Inserting these methods in your application will, of course, consume resources at runtime but the performance impact should be minimal.
This method returns a monotonic timer value by using the most precise available system timer. The returned value is in nanoseconds, however the factual resolution of the timer can vary between OS and hardware. Note that there is no conventional zero point to which you can relate the timer value. Hence, you must take the time at least twice in order to get any meaningful data.
nanoTime() uses different methods on different operating systems:
To get information about timer resolution and, on Linux, the method used to get a time value, start the JRockit JVM with the option -Xverbose:timing.
Here is an example of a verbose timing report on Windows:
[INFO ][timing ] Counter timer using resolution of 1779720000Hz
This method returns the current time in milliseconds. The current time is defined as the time since 00:00:00 UTC, January 1, 1970.
To get the values of System.currentTimeMillis() and System.nanoTime() at the time the JVM started, use the command line option -Xverbose:starttime. Verbose output for starttime might look like this:
[startti] VM start time: 1152871839957 millis 171588375730523 nanos
The millis value is the same value that System.currentTimeMillis() would provide and the nanos value is the same value that System.nanoTime() would provide.
This section provides information on possible solutions for a slow start.
Sometimes the problem may be with how the JVM is tuned using command line options. See Tuning For Faster JVM Startup for tips on how to tune the JVM for faster startup.
Since, on some rare occasions, optimization can be the cause of a slow start, you should eliminate it as a cause before you move on to any other solution.
If you suspect that the problem is with optimization, you can disable optimization completely by starting the JVM with the
-XnoOpt startup command. This command tells the JVM not to optimize any code. If the JRockit JVM starts more quick after running with -XnoOpt, you can assume your are experiencing optimization problems. You should report this to Oracle Support.
As a workaround you can try to exclude methods that take too long to optimize. To do so, use the Ctrl-Break Handler print_threads to make a thread dump (please refer to Running Diagnostic Commands for more information). This output will identify any methods that are causing optimization problems. You can then use an optfile to exclude that method from the optimization process (please refer to Creating and Using an Optfile for more information).
If you determine that the slow start is due to problems in your Java application, you need to investigate what is causing that problem from the application viewpoint. The problem will most likely be with a method that is the victim of unnecessary synchronization or an insufficient number of synchronized resources. Try to locate the methods that are causing the bottleneck and, if possible, rewrite the code of your Java application.
If you feel that it is the Oracle JRockit JVM that is taking too long to generate the code for each method or if none of the tuning solutions suggested in Tuning For Faster JVM Startup resolve the problem, you will need to open a case with Oracle Support. You can find instructions on how to report a problem to Oracle, including the sort of information to include, in Submitting Problems to Oracle Support
|