Tuning JRockit JVM
When you install BEA JRockit JVM, it includes a host of default start-up options that ensure a satisfactory out-of-the-box experience; however, often, these options might not provide your application with the optimal performance you should experience with BEA JRockit JVM. Therefore, BEA JRockit JVM comes with numerous alternative options and algorithms to suit different applications. This section describes some of these options and some basic tuning techniques you can use at startup. It includes information on the following subjects:
Note: The tuning settings discussed in this section refer to standard and non-standard tuning options which are not thoroughly described in the present context. For more information on these options, please refer to Tuning BEA JRockit JVM.
Before you start BEA JRockit JVM, you need to determine these two factors:
Once you've answered these questions, use the information provided below to tune BEA JRockit JVM to achieve those goals.
Generally, you want to set the maximum heap size as high as possible, but not so high that it causes page-faults for the application or for some other application on the same computer. Heap sizing is accomplished by using the -Xms
(minimum heap size) and -Xmx
(maximum heap size) options. For details on these options and guidelines for sizing the heap, please refer to Setting the Heap Size in Tuning BEA JRockit JVM.
As mentioned above, you need to consider how you want BEA JRockit to perform: for the highest possible responsiveness or the highest possible performance? This section describes how to tune for either type of performance.
If you want the highest responsiveness from your application and guarantee minimal pause times, do the following:
-Xgc:gencon
). -Xms
) and maximum (-Xmx
) heap sizes, as described in Set the Heap Size. If you're using a fixed, generational concurrent garbage collector, a larger heap reduces the frequency of garbage collection and will allow collection at less intrusive points. This will prevent longer pauses.-Xns
).If you are creating a lot of temporary objects you should have a large nursery. Larger nurseries usually result in slightly longer pauses, so, while you should try to make the nursery as large as possible, don't make it so large that pause times are unacceptable. You can see the nursery pause times in BEA JRockit JVM by starting the JVM with -Xgcpause
.
If you want the highest possible performance BEA JRockit can provide, you will want to optimize memory thoughput. Set these tuning options at startup:
Xns
.-Xms
) and maximum (-Xmx
) heap sizes that your machine can tolerate, as described in Set the Heap Size.
This section describes other practices you can employ to improve BEA JRockit JVM performance.
The JRockit Runtime Analyzer (JRA) is a great way to look at the performance of JRockit. The JRA records what happens in your system in runtime and then saves the findings in a file that can be analyzed through a separate JRA tool. The recording contains information about, for example, memory usage, Java heap content, and hot methods. For information on how to use the JRA, see:
Using the JRockit Runtime Analyzer
Analyzing garbage collection and pause times together will give you a good idea of how well your application is performing while running with BEA JRockit JVM.
Use the option -Xgcreport
to generate and end-of-run report that shows the garbage collection statistics. You can use this report to determine if you're using the most effective garbage collector for your application. As shown in Listing 3-1, the -Xgcreport
shows a detailed profile of collections on both the nursery and the old generation (in this case, the garbage collector was generational).
Listing 3-1 -Xgcreport Output: Generational Garbage Collector
[memory ]
[memory ] Memory usage report
[memory ]
[memory ] young collections
[memory ] number of collections = 201
[memory ] total promoted = 395672 (size 11807976)
[memory ] max promoted = 3797 (size 113720)
[memory ] total GC time = 5.994 s
[memory ] mean GC time = 29.819 ms
[memory ] maximum GC Pauses = 48.175 , 54.541, 81.423 ms
[memory ]
[memory ] old collections
[memory ] number of collections = 24
[memory ] total promoted = 0 (size 0)
[memory ] max promoted = 0 (size 0)
[memory ] total GC time = 4.083 s (pause 1.812 s)
[memory ] mean GC time = 170.125 ms (pause 75.498 ms)
[memory ] maximum GC Pauses = 0.489 , 2.213, 99.671 ms
[memory ]
[memory ] number of concurrent mark phases = 7
[memory ] number of parallel mark phases = 17
[memory ] number of concurrent sweep phases = 8
[memory ] number of parallel sweep phases = 16
By using this report, you can determine where performance is being impacted during garbage collection. For example, you might determine that pause times are too long change from a static garbage collector to a dynamic one that attempts to minimize pause time by setting -Xgcprio:pausetime
.
For more information on using -Xgcreport
, see Viewing Garbage Collection Activity in Using the BEA JRockit Memory Management System
Use the option -Xverbose:memory
to display the pause times for every garbage collection during a run. Note that this option is used mainly for debugging purposes as it creates a lot of output to the console. For information on using -Xverbose
, please refer to Displaying Logging Information in Starting and Configuring BEA JRockit JVM.
If your application consists of a fairly small active portion (less than a couple of 100 lines of code being accessed more than 80% of the time) and the application is heavily mutlithreaded with multiple threads accessing the active portion, you may be able to speed up your application by specifying -XXdisablefatspin
. This option disables a lock optimization in JRockit.