This chapter describes the -XX command-line options of Oracle JRockit JVM; these options are all prefixed by -XX.
To implement some of the options, specific system requirements must be met, otherwise, the particular option does not work. Oracle recommends that you use these options only if you have a thorough understanding of your system. Improper usage of these options can affect the stability or performance of your system.
Note:
The-XX options are subject to change at any time.In this chapter, all the -XX command-line options that you can use with the JRockit JVM are listed in the alphabetical order.
Notes:
Command-line options are case sensitive unless explicitly stated. Most of the commands use the camel notation (for example, -XXgcThreads and -XXcompaction).
Some command-line options use the HotSpot implementation format; that is, you must place the colon (:) between the -XX and the option name followed by a the necessary operator to indicate enabling (+) or disabling (-) the new hash function.
If you do not add a unit with the values of options that specify memory size, you get the exact value; for example, 64 is considered as 64 bytes, not 64 megabytes or 64 kilobytes.
-XXcompactSetLimit (deprecated)
-XXcompactSetLimitPerObject (deprecated)
-XX:+|-CrashOnOutOfMemoryError
-XX:ExitOnOutOfMemoryErrorExitCode
-XXexternalCompactRatio (deprecated)
-XX:+|-FlightRecordingDumpOnUnhandledException
-XX:+|-HeapDiagnosticsOnOutOfMemoryError
-XX:+|-HeapDumpOnOutOfMemoryError
-XXinternalCompactRatio (deprecated)
-XXlargeObjectLimit (deprecated)
-XX:SegmentedHeapDumpThreshold
-XX:+|-UseLargePagesFor[Heap|Code]
The -XXaggressive option is a collection of configurations that make the JVM perform at a high speed and reach a stable state as soon as possible. To achieve this goal, the JVM uses more internal resources at startup; however, it requires less adaptive optimization once the goal is reached.
What this option configures is subject to change between releases.
When you combine this option with -XX:+UseAllocPrefetch, the -XX:AllocChunkSize option sets the size of the chunks to be cleared.
If you enable this option at startup, the JRockit JVM verifies all arguments to JNI calls, and when it detects an illegal JNI call, the JVM terminates with an error message describing the transgression.
-XX:+CheckJNICalls is equivalent to -Xcheck:jni.
This option specifies whether the JVM should explicitly check for stack overflows on a JNI method entry.
Compaction moves live objects closer together in the Java heap to create larger, contiguous free areas that can be used for allocation of large objects. When the JVM compacts the heap, all threads should be paused because the objects are being moved around. To reduce pause time, only a part of the heap is compacted.
-XXcompaction:parameter1=value1[,parameter2=value2]
Table 3-1 lists the parameters that you can specify for the -XXcompaction option.
Table 3-1 Parameters for -XXcompaction
java -XXcompaction:heapParts=8000,internalPercentage=0.5 myApp
When you set this option on a 2 GB heap, it compacts 10 MB of the heap at each internal compaction.
When using the -XXcompaction option, consider the following:
Do not use parameters that conflict each other in the same -XXcompaction option:
The percentage parameter conflicts with the internalPercentage and externalPercentage parameters.
The full parameter conflicts with other percentage parameters such as percentage, initialPercentage, internalPercentage, and externalPercentage
You cannot set the abortable parameter to false.
When you set the enable parameter to false, a warning is printed
Parameters that are specified later in the command line override parameters specified earlier.
The -XXcompactRatio option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:percentage instead. For more information, see -XXcompaction.
For more information about the format and usage of -XXcompactRatio, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
The -XXcompactSetLimit option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:maxReferences instead. For more information, see -XXcompaction.
For more information about the format and usage of -XXcompactSetLimit, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
The -XXcompactSetLimitPerObject option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:maxReferencesPerObject instead. For more information, see -XXcompaction.
For more information about the format and usage of -XXcompactSetLimitPerObject, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
The -XXcompressedRefs option governs the use of compressed references, limiting all pointers stored on the heap to 32 bits. Compressed references use fewer Java heap resources and transport less data on the memory bus and improves the performance. This option also frees space on the heap.
Note:
-XXcompressedRefs is equivalent to -XX:CompressedRefs.-XXcompressedRefs:parameter=value
Use the command with one of the parameters listed in Table 3-2 to specify the behavior of compressed references.
Table 3-2 Parameters for -XXcompressedRefs
| Parameter | Description |
|---|---|
enable=true|false |
Enables or disables compressed references. |
size=4GB|32GB|64GB |
Specifies the size of compressed references. The default size varies for different heap sizes as listed in Table 3-3. |
java -Xgc:pausetime -XXcompressedRefs:enable=true myApp
java -Xgc:pausetime -XXcompressedRefs:size=32GB myApp
If -XXcompressedRefs is not specified, compressed references are enabled on all 64-bit machines as long as the heap size is less than 4 GB. When you use the -Xmx option, the default values vary on the heap size as listed in Table 3-3.
Table 3-3 Default Size of Compressed References
| Heap Size | Default Size of Compressed References |
|---|---|
|
-Xmx:3g or lower |
4 GB |
|
-Xmx:25g or lower |
32 GB |
|
-Xmx:57g or lower |
64 GB |
Other command-line options are affected by -XXcompressedRefs as described here:
If you use this option with an initial heap size (-Xmx) that is too large, execution will stop and an error message are generated.
If you do not specify compressed references explicitly by using the -XXcompressedRefs option and you specify either an initial heap (-Xms) or a maximum heap (-Xmx) that is too large (more than 64 GB) for compressed references, compressed references will not be used. The JVM will not stop; it will run normally.
If this option is enabled, when an out-of-memory error occurs, the JRockit JVM crashes and produces text and binary crash files.
Note:
This option is new in R28.1. It does not work in R28.0.Note that generation of crash files when the JVM crashes is enabled by default. For more information, see "About Crash Files" in the Oracle JRockit Diagnostics and Troubleshooting Guide.
This option specifies whether tools (such as jrcmd and jconsole) are allowed to attach to the JRockit JVM.
Usually when the JRockit JVM crashes, it saves out the state of the process (called a core dump). When you use -XXdumpFullState, the JVM saves all the process state including the heap. More disk space is used, but it makes much easier for you to use the core dump to find out what the problem was that caused the crash. This option saves a significant amount of information to disk.
-XXdumpFullState is equivalent to -XXdumpsize:large. For more information, see -XXdumpSize.
The -XXdumpSize option causes a dump file to be generated and allows you to specify the relative size of that file.
-XXdumpsize:size
Use the command with one of the parameters listed in Table 3-4 to specify the relative size of the dump file.
Table 3-4 Parameters for -XXdumpsize
| FIle Size | Description |
|---|---|
none |
Does not generate a dump file. |
small |
On Windows, a small dump file is generated (on Linux a full core dump is generated). A small dump only include the thread stacks including their traces and very little else.). |
normal |
Causes a normal dump to be generated on all platforms. This dump file includes all memory except the java heap. |
large |
Includes everything that is in memory, including the Java heap. This option makes |
Specify this option at startup to filter exception logging. JRockit JVM logs only those exceptions that match a type specified by this option.
-XX:ExceptionTraceFilter=java.lang.Exception
Enter this command at startup to log exceptions of type java.lang.Exception class.
When you enable this option, JRockit JVM exits on the first occurrence of an out-of-memory error. It can be used if you prefer restarting an instance of JRockit JVM rather than handling out of memory errors.
-XX:+|-ExitOnOutOfMemoryError
Enter this command at startup to force JRockit JVM to exit on the first occurrence of an out of memory error.
This option specifies the exit code for termination of the JVM process when an out-of-memory error occurs.
This option works with the -XX:+|-ExitOnOutOfMemoryError option
The -XXexternalCompactRatio option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:externalPercentage instead. For more information, see -XXcompaction.
For more information about the format and usage of -XXexternalCompactRatio, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
This option specifies whether a failover happens to the old verifier when the new type checker fails.
This option enables or disables the JRockit Flight Recorder. If JRockit Flight Recorder was disabled at application startup, you cannot enable it at run time.
This option is enabled, but there are no recordings running by default. Use the -XX:FlightRecorderOptions to specify options and to start a recording.
This option enables or disables the JRockit Flight Recorder arguments. It is used only when the JRockit Flight Recorder is enabled.
-XX:FlightRecorderOptions=parameter1=value[,parameter2=value]
Table 3-5 lists the parameters for -XX:FlightRecorderOptions.
Table 3-5 Parameters for -XX:FlightRecorderOptions
| Parameter | Description | Default Value |
|---|---|---|
defaultrecording=true|false |
Specifies whether the background recording is enabled or disabled. |
false |
disk=true|false |
Specifies whether JRockit Flight Recorder should write the continuous recording to a disk. |
false |
dumponexit=true|false |
This parameter is new in R28.1. It does not work in R28.0. Specifies whether a dump of Flight Recording data should be generated when the JVM terminates in a controlled manner. The dump file is written to the location defined by the |
false |
dumponexitpath=path
|
This parameter is new in R28.1. It does not work in R28.0. Specifies the path and name of the dump file (containing Flight Recorder data), which is created (if If the specified path is a directory, the JVM assigns a filename that shows the creation date and time. If the specified path includes a filename and if that file that already exists, the JVM creates a new file by appending the date- and time-stamp to the specified filename. |
|
globalbuffersize=size
|
Specifies the total amount of primary memory used for data retention. |
10 MB |
maxage=time
|
Specifies the maximum age of disk data for default recording. This option is valid only when the parameter |
15 minutes |
maxchunksize=size
|
Specifies the maximum size, in megabytes, of the data chunks in a recording. |
12 MB |
maxsize=size
|
Specifies the maximum size of disk data for default recording. This option is valid only when the parameter |
Unbound |
repository=file_location
|
Specifies the repository (a directory) for temporary disk storage. |
The default location is the system temporary directory. |
settings=file_location
|
Specifies the name and location for the event settings ( For more information about the event settings file, see "Events" in Oracle JRockit Flight Recorder Run Time Guide. |
|
threadbuffersize=size
|
Specifies the per-thread local buffer size. Higher values for this parameter allow more data gathering without contention to flush it to the global storage. It can increase application footprint in a thread-rich environment. For more information about buffers, see "JFR Buffers" in Oracle JRockit Flight Recorder Run Time Guide. |
5 KB |
This option works only when the -XX:+|-FlightRecorder option is enabled.
This option, when enabled, generates a Flight Recording dump when a thread is terminated due to an unhandled exception. The dump file is written to the location defined by the -XX:FlightRecordingDumpPath option.
This option specifies the path and name of the dump file (containing Flight Recorder data), which is created (if the -XX:+|-FlightRecordingDumpOnUnhandledException is enabled) when a thread is terminated due to an unhandled exception.
The default Flight Recording dump file is present in the working directory as jrockit_pid_thread_id.jfr (where pid represents the JRockit process identifier and thread_id represents the thread for which the unhandled exception is thrown).
The -XXfullSystemGC option causes the garbage collector to do a full garbage collection every time System.gc() is called. Full garbage collection includes old space collection and the elimination of soft references. Use this option when you want the garbage collector to do maximum garbage collecting every time you explicitly invoke a garbage collection from Java.
This option is useful when the default garbage collector does not free enough memory; however, using it can cause longer garbage collection pauses.
-XXfullSystemGC
When you use this option, if an old space collection is already running when System.gc() is called, it will first wait for it to finish and then trigger a new old space collection. The -XXfullSystemGC option frees all softly referenced objects.
You cannot use -XXfullSystemGC together with -XXnoSystemGC.
This option specifies how many garbage collection threads the garbage collector will use. This applies both to parallel nursery and parallel old space collectors as well as the concurrent and deterministic collector.
-XXgcthreads:parameter1=value1,parameter2=value2,...
Use the command with one of the parameters listed in Table 3-6 to specify the number of threads used by the garbage collector.
Note:
If you specify a number instead of theparameter, that number determines the number of garbage collection threads used for garbage collection during parallel phases. This is equivalent to using the parameter all=number.
Example:
java -XXgcThreads:4 myApp
Table 3-6 Parameters for -XXgcThreads
| Parameter | Description |
|---|---|
all=number of threads
|
Specifies the same number of garbage collection threads for all garbage collectors (young, concurrent, and parallel). |
yc=number of threads
|
Specifies the number of garbage collection threads that the young collector uses in parallel. |
con=number of threads
|
Specifies the number of garbage collection threads that the old collector uses in parallel during concurrent phases. |
par=number of threads
|
Specifies the number of garbage collection threads that the old collector uses in parallel during the stopped (paused) phases. |
The -XX:GCTimePercentage option determines the percent of time spent in garbage collection of total run time.
-XX:GCTimePercentage=nn
nn is the time spent in garbage collection.
-XX:GCTimePercentage can be used as an alternative to -XX:GCTimeRatio.
When you set -XX:GCTimePercentage to 5, five percent of the total time is spent in garbage collection; it is equivalent to -XX:GCTimeRatio=19.
The -XX:GCTimeRatio option specifies the ratio of the time spent outside the garbage collection (for example, the time spent for application execution) to the time spent in the garbage collection.
-XX:GCTimeRatio=nn
nn is a number that specifies the ratio of the time spent (as number of times).
The default value is 19, which means that the time outside the garbage collection is 19 times the time spent in garbage collection.
This option determines how much free memory should remain on the heap when a concurrent garbage collection starts. If the heap becomes full during the concurrent garbage collection, the Java application cannot allocate more memory until the garbage collection frees some heap space, which might cause the application to pause. While the trigger value will tune itself in run time to prevent the heap from becoming too full, this automatic tuning might take too long. Instead, you can use -XXgcTrigger to set from the start a garbage collection trigger value more appropriate to your application.
If the heap becomes full during the concurrent mark phase, the sweep phase will revert to parallel sweep. If this happens frequently and the garbage collection trigger does not increase automatically to prevent this, use -XXgcTrigger to manually increase the garbage collection trigger.
-XXgcTrigger=nn
where nn is the amount of free heap, as a percent of the heap, available when a garbage collections triggered. Note that the young space is not considered as part of the free heap.
java -XXgcTrigger=50 myApp
With this option set, JRockit JVM will trigger a garbage collection when 50% of the heap. For example, about 512 MB on a 1 GB heap or less remains free. The current value of the garbage collection trigger will appear in the -Xverbose:memdbg outputs whenever the trigger changes.
If -XXgcTrigger is not specified, the system tries to automatically find a good percentage value. If -XXgcTrigger=nn is specified, it is used instead and no automatic process is involved.
This option specifies whether the JVM should print Java heap diagnostics when an out-of-memory error occurs. The dump file is written to the location defined by the -XX:HeapDumpPath option.
This option specifies the path and file name of the dump file if you have enabled the -XX:+|-HeapDiagnosticsOnOutOfMemoryError option.
The default name of the dump file is jrockit_pid.oomdiag, and the default path is the working directory.
This option works with the -XX:+|-HeapDiagnosticsOnOutOfMemoryError option.
The -XX:HeapDumpOnCtrlBreak option adds the hprofdump diagnostic command to the list of commands that run automatically when the Ctrl-break keys are pressed (similar to the print_threads diagnostic command). The HPROF dump file is written to the location defined by the -XX:HeapDumpPath option.
If you enable the -XX:+|-HeapDumpOnOutOfMemoryError option, the JRockit JVM dumps the Java heap in HPROF binary format (.hprof file) when an out-of-memory error occurs.
The -XX:HeapDumpPath option specifies the path and file name of the HPROF dump file if you have used -XX:+HeapDumpOnOutOfMemoryError option.
The default name of the binary dump file is jrockit_pid.hprof, where pid represents the JRockit process identifier, and the default path is the working directory.
This option works with the -XX:+|-HeapDumpOnOutOfMemoryError and -XX:+|-HeapDumpOnCtrlBreak options.
The -XX:HeapDumpSegmentSize option specifies an appropriate segment size when generating a segmented HPROF heap dump.
No segments are generated unless heap size is larger than the value specified by the -XX:SegmentedHeapDumpThreshold option.
The -XXheapParts option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:heapParts instead. For more information, see -XXcompaction.
For more information about the format and usage of -XXheapParts, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
The -XXinternalCompactRatio option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXcompaction:internalPercentage instead. For more information, see -XXcompaction.
For more information about the format and usage of -XXinternalCompactRatio, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
The -XX:+|-JavaDebug option enables or disables the debugging capabilities that the JVM Tools Interface (JVMTI) uses. JVMTI is a low-level debugging interface used by debuggers and profiling tools, to inspect the state and control the execution of applications running in the JVM.
Note that the subset of JVMTI that is most typically used by profilers is always enabled. However, the functionality used by debuggers to be able to step through the code and set break points has some overhead associated with it and is not always enabled. To enable this functionality, use the -XX:+JavaDebug option.
Caution:
Do not use the-XX:+JavaDebug option in the production environment, because, when running with the -XX:+JavaDebug option, the JVM does not run at full speed.
java -XX:+JavaDebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=n myApp
For more information about the -agentlib option, see the Java documentation at the following locations:
This option is equivalent to the -Xdebug option.
The -XXkeepAreaRatio option sets the size of the keep area within the nursery as a percent of the nursery. The keep area prevents newly allocated objects from being promoted to old space too early.
By default, the keep area is 25% of the nursery size. The keep area should not exceed 50% of the nursery size.
The -XXlargeObjectLimit option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXtlaSize:wasteLimit instead. For more information, see -XXtlaSize.
For more information about the format and usage of -XXlargeObjectLimit, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
The -XX:MaxCodeMemory option specifies the maximum memory used for generated code.
On Windows IA32, Linux IA32, Windows x86_64, and Linux x86_64, the default value is unbounded. If the -XX:+ReserveCodeMemory option is specified on these platforms, the default maximum code memory is as follows:
When you use -XX:+UseLargePagesForCode: 64 MB
When you use -XX:-UseLargePagesForCode: 1024 MB
On Solaris SPARC the default maximum code memory is 256 MB.
This option specifies the maximum total size of java.nio (New I/O package) direct buffer allocations.
The -XX:MaximumNurseryPercentage option allows you to set an upper nursery size limit that is relative to the free heap space available after the latest old collection. You must specify the limit as a percentage value of the available free heap size.
-XX:MaximumNurseryPercentage=<value> [1-95]
If you try to set the upper nursery size limit to a value lower than 1 or higher than 95, an error message is displayed.
This option specifies the maximum size for large pages.
The default value is zero in JRockit versions R28.0.0 to R28.2.2. This means that this value is specified by the operating system.
For JRockit versions R28.2.3 and later, the default value is 256 MB.
The option is valid only if -XlargePages or -XX:+|-UseLargePagesFor[Heap|Code] is specified.
This option specifies the maximum size of the receive buffer when reading from network sockets.
This option is applicable only to Windows.
Note:
This option is new in R28.1. It does not work in R28.0.If you set this option to 0, the receive buffer size is unlimited, which is the behavior in R28.0.
The -XXminBlockSize option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XXtlaSize:min instead. For more information, see -XXtlaSize.
For more information about the format and usage of -XXminBlockSize, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
The -XXnoSystemGC option prevents a call to the System.gc() method from starting a garbage collection. For more information about the System.gc() method, see the specification for the java.lang.System at the following locations:
Java SE 6.0
J2SE 5.0
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html
If your application uses System.gc() and you want to the garbage collector itself to decide when to run the collection, you should use this option. This option is useful in some debugging situations and can also enhance performance as it prevents unnecessary garbage collection from happening.
-XXnoSystemGC
Enter the command in the above format at startup. This option can cause longer garbage collection pauses in some cases, but generally, it makes the application perform better.
You cannot use -XXnoSystemGC together with -XXfullSystemGC.
The -XX:OptThreads option specifies the number of threads the JVM uses for the optimization of Java methods. The optimization of Java methods runs in the background.
java -Xgc:pausetime -XX:OptThreads=3 myApp
Directs the compiler to use three threads for optimization tasks.
With this option, an additional chunk (that is, two chunks subsequent) is fetched whenever a new chunk is used.
Note:
To get the full benefit from this feature on Intel Xeon servers, Oracle recommends that you disable hardware prefetching in the BIOS of the computer.This option will not work unless -XX:+|-UseAllocPrefetch is set.
When this option is enabled, the JVM reserves the memory for generated code at startup.
This option is enabled by default on Solaris SPARC, Windows x86_64, and Linux x86_64 platforms. The default value depends on the -XX:+|-UseLargePagesForCode option as follows:
When you use -XX:+UseLargePagesForCode: 64 MB
When you use -XX:-UseLargePagesForCode: 1024 MB
On Solaris SPARC the default code memory is 256 MB.
The -XX:SegmentedHeapDumpThreshold option generates a segmented heap dump (.hprof file, 1.0.2 format) when the heap usage is larger than the specified size.
The segmented hprof dump format is required to correctly generate heap dumps containing more than 4 GB of data. If the value of -XX:SegmentedHeapDumpThreshold option is set more than 4 GB, heap dumps may not be generated correctly.
This option can be used with -XX:+|-HeapDumpOnOutOfMemoryError.
The -XXsetGC option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -Xgc instead. For more information, see -Xgc.
For more information about the format and usage of -XXsetGC, see the R27 release documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
When you enable this option, JRockit JVM enables strict floating point arithmetics globally for all methods in all classes. The JVM also calculates with more precision, and with a greater range of values than the Java specification requires. When you use this option, the compiler generates code that adheres strictly to the Java specification to ensure identical results on all platforms. When you do not use this option, the JVM does not enforce floating point values.
This option is similar to the Java keyword strictfp; however, that keyword applies at the class level whereas -XX:+|-StrictFP applies globally. For more details about the strictfp keyword, see the Java Language Specification at:
http://java.sun.com/docs/books/jls/
This option is equivalent to -XstrictFP.
Specify this option at startup to start a Flight Recorder recording for an application that runs on JRockit JVM. This option is equivalent to the start_flightrecording diagnostic command that starts the Flight Recorder at run time. For more information, see Oracle JRockit JDK Tools.
-XX:StartFlightRecording=parameter1=value1[,parameter2=value2]
Use -XX:StartFlightRecording with the parameters listed in Table 3-7.
Table 3-7 Parameters for -XX:StartFlightRecording
| Parameter | Description | Default Value |
|---|---|---|
compress=true|false |
Specifies whether to compress the Flight Recorder recording log file ( the .jfr file) on the disk using the gzip file compression utility. This parameter is valid only if the |
false |
defaultrecording=true|false |
Specifies whether the recording is continuous or it runs for a limited time. |
false |
delay=time
|
Specifies the time to elapse during run time before starting the recording. |
0 |
duration=time
|
Specifies the time for the recording. |
Unlimited |
filename=name
|
Specifies the name of the Flight Recorder recording log file (the .jfr file). |
None |
name=identifier
|
Specifies an identifier for the Flight Recorder recording. |
Recording |
maxage=time
|
Specifies the maximum age of disk data for default recording. |
15 minutes |
maxsize=size
|
Specifies the maximum disk space for a recording. This parameter is valid only for the size-bound recordings. |
Unbound |
settings=eventfile
|
Specifies the event setting file to use for the recording. You can use this parameter multiple times in one command. |
|
The -XXtlaSize option sets the thread-local area size.
To increase performance JRockit JVM uses thread-local areas (TLA) for object allocation. This option can be used to tune the size of the thread-local areas, which can affect performance.
-XXtlaSize:parameter=size[k|K][m|M][g|G]
Table 3-8 lists the parameters.
Table 3-8 -XXtlaSize Parameters
| Parameter | Description |
|---|---|
min=size
|
Sets the minimum size of a TLA. |
preferred=size
|
Sets the preferred size of a TLA. The system will try to get TLAs of this size if possible, but will accept TLAs down to the minimum size, if that's what's available. Occasionally, a TLA can get larger than the preferred size, too. The preferred size must not be lower than the minimum size. |
wasteLimit=size
|
Sets the waste limit for TLAs. This is the maximum amount of free memory that a TLA is allowed to have when a thread requires a new TLA. |
There are no upper or lower limits to -XXtlaSize.
Use this option with caution, as changing the thread-local area size can have severe impact on the performance.
Specify size in bytes, using the normal k,M,G suffixes.
Note:
The old style for setting TLA size (that is,-XXtlasize=256k) is supported but has been deprecated. If you use the old style, JRockit JVM interprets the option as if the preferred parameter was used; so -XXtlasize=256k would be interpreted as -XXtlasize:preferred=256k.The default value for both the minimum size and the waste limit is 2 KB. The waste limit cannot be set to a larger value than the minimum size.
The default value for the preferred size depends on the heap size or the nursery size and the garbage collector selected at startup.Table 3-9 lists the default sizes for the different configurations.
Table 3-9 Default Preferred TLA Sizes
| Garbage Collectors | Default Preferred TLA Size |
|---|---|
-Xgc:deterministic, -Xgc:singlecon |
16 KB |
-Xgc:pausetime, -Xgc:gencon |
16 KB - 256 KB depending on the nursery size |
-Xgc:throughput, -Xgc:genpar |
16 KB - 64 KB depending on the heap size |
-Xgc:parallel |
16 KB - 256 KB depending on the heap size |
|
Nursery size set with |
16 KB - 256 KB depending on the nursery size |
The following relation is true for the TLA size parameters:
-XXtlaSize:wasteLimit <= -XXtlaSize:min <= -XXtlaSize:preferred
If you set two or more of the options, then you must make sure that the values you use fulfil these criteria. By default, the waste limit is set to whichever is the lower value of the minimum TLA size and the preferred TLA size divided by 2.
This option specifies the size of the entry array in each java.util.TreeMap node. This option affects the JVM performance and the default value is appropriate for most of the applications.
This option specifies whether threads should spin against a fat lock or not (and directly go to sleep state when failed to acquire the fat lock).
With this option a Thread Local Area is split into chunks and, when a new chunk is reached, the subsequent chunk is prefetched.
Note:
To fully benefit from this feature on Intel Xeon servers, it is recommended that you disable hardware prefetching in the BIOS of the computer.This option must be set if you want to use -XX:+|-RedoAllocPrefetch. This option is also used with the -XX:AllocChunkSize option.
This option enables the use of call profiling for code optimizations. Profiling records useful run-time statistics specific to the application and can increase performance because the JVM can then act on those statistics.
When enabled, this option uses a version of yield adapted for the Completely Fair Scheduler (CFS). This option should be used only on CFS and only if you are experiencing performance issues with the JVM.
Note:
This option is available only on Linux.This option enables or disables garbage collection of classes.
When you disable garbage collection of classes, you can save some garbage collection time, which minimizes interruptions during the application run. Disabling garbage collection of classes can result in more memory being permanently occupied; so if the option is not used carefully, the JVM throws out-of-memory error.
Note:
Oracle recommends that you do not disable this option unless required because it can lead to memory leak when the application is running.This option enables or disables garbage collection of constant pool strings.
When you disable garbage collection of constant pool strings, you may be able to reduce some garbage collection overhead associated with removal of strings from the runtime shared pool. Disabling garbage collection of constant pool strings can result in more memory being permanently occupied. Therefore, if the option is not used carefully, the JVM may throw an out-of-memory error.
Note:
This option is available since JRockit R28.3.2.Oracle strongly recommends that you do not disable this option unless requested by Oracle Support because it can lead to a memory leak when the application is running.
Even with constant pool garbage collection disabled, there are still cases where the JVM can determine that certain strings are no longer needed and are removed from the constant pool without the help of the garbage collection system.
java -XX:-UseCPoolGC myApp
The constant pool strings in the application specified by myApp are left untouched during garbage collection and may never be removed.
This option specifies the use of hardware support for low-latency timestamps.
Note:
If you enable this option on a platform that does not support hardware timestamps, it might cause JRockit JVM to use invalid timestamps and it can result in fatal errors.The -XX:-UseFatSpin option disables the fat lock spin code in Java, allowing threads that block trying to acquire a fat lock go to sleep directly.
Objects in Java become a lock as soon as any thread enters a synchronized block on that object. All locks are held (that is, stay locked) until released by the locking thread. If the lock is not going to be released very fast, it can be inflated to a fat lock. Spinning occurs when a thread that wants a specific lock continuously checks that lock to see if it is still taken, spinning in a tight loop as it makes the check. Spinning against a fat lock is generally beneficial although, in some instances, it can be expensive and might affect performance. The -XX:-UseFatSpin allows you to turn off spinning against a fat lock and eliminate the potential performance hit.
This option enables the use of large pages, if they are available, for the Java heap and code in the JVM. Large pages allow your application to more effectively use the translation look-aside buffer (TLB) in the processor.
Note:
This option duplicates the functionality of the -XlargePages option. Oracle recommends that you use the-XX:+|-UseLargePagesFor[Heap|Code] option instead of using the -XlargePages option.
Use the extended option (-XX:+ForceLargePagesForHeap) to force the JVM to exit if enough large pages cannot be acquired and you have used the -XX:+UseLargePagesForHeap option.
When -XX:+|-UseLazyUnlocking is enabled, locks are not released when a critical section is exited. Instead, once a lock is acquired, the next thread that tries to acquire such a lock will have to ensure that the lock is or can be released. It does this by determining if the initial thread still uses the lock. A truly shared lock is eventually converted to a normal lock and this improves the performance of locking operations on shared locks.
Lazy unlocking is enabled by default on all platforms except when the -Xdebug option is used.
The -XX:+|-UseLockProfiling option enables or disables profiling of Java locks in JRockit Flight Recorder.
To get the Java lock profiling data, the lock events in the JRockit Flight Recorder must also be enabled. For more information, see Oracle JRockit Flight Recorder Run Time Guide.
This option directs the JVM to use the low 4 GB address space for Java heap, if available.
This option specifies whether a new, faster hash function is enabled for java.util.HashMap. This hash function can improve performance through improved hash spread, but changes the order in which elements are stored in the HashMap.
This option enables you to control the priority of Java threads using java.lang.Thread.setPriority() and related APIs. If this feature is disabled, using these APIs has no effect.
Caution:
This feature is experimental and not supported by Oracle at this time. Improper use can cause serious performance issues.-XX:+UseThreadPriorities
Enables use of the java.lang.Thread.setPriority() and related APIs.