This section describes Oracle JRockit JVM’s -XX
command-line options; these options are all prefaced by -XX
. To implement some of the options, specific system requirements must be met, otherwise, the particular option will not work. We recommend that you use these options only
These options are subject to change without notice.
Note: | This section contains an ever-changing list of options and is continually republished as necessary to include any new -XX options and to indicate any deprecated -XX options. |
-XXaggressive
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. We recommend that you use this option for long-running, memory-intensive applications that work alone.
Note: | What this option configures is subject to change between releases. |
Combine -XXaggressive
with one of the parameters listed in
Table 3-1
By specifying -XXagressive
with the opt
parameter, adaptive optimizations will be scheduled earlier in runtime and new optimizations will be enabled.
If neither opt
nor memory
is specified, the application will run as if both were specified.
This option will set several things, which can be reset or changed by adding the explicit options on the command line after -XXaggressive
.
This option allows you to clear a TLA for references and values at TLA allocation time and pre-fetch the next chunk. When an integer, a reference, or anything else is declared, it has a default value of 0 or null (depending upon type). At the appropriate time, you will need to clear these references and values to free the memory on the heap so Java can use—or reuse—it. You can do either when the object is allocated or, by using this option, when you request a new TLA.
-XXallocClearChunks=<true | false>
This is a boolean option and is generally recommended on IA64 systems; ultimately, its use depends upon the application. If you want to set the size of chunks cleared, combine this option with -XXallocClearChunkSize.
By default, this mechanism is disabled. If you use this option but do not specify a boolean value, the default is true
.
While this mechanism is, by default, disabled, it is included in aggressive:memory
on IA64 systems.
When used with -XXallocClearChunkSize, this option sets the size of the chunks to be cleared.
Format: -XXallocClearChunks
-XXallocClearChunkSize=
<size>
[k|K][m|M][g|G]
Combine this option with – XXallocClearChunks
to set the size of the chunks to be cleared
java -XXallocClearChunks
-XXallocClearChunkSize=256m
myApp
If this option is used but no value is specified, the default is 512 bytes.
See
Operation for a description of how this option works with -XXallocClearChunks.
This option cannot be used unless
-XXallocClearChunks
is also used.
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, you should disable hardware prefetching in the computer’s BIOS. |
Format: -XXallocPrefetch[=true|false]
To enable: java -XgcPrio:pausetime
-XXallocPrefetch
myApp
To disable: java
-XgcPrio:pausetime
-XXallocPrefetch=false
myApp
This feature is enabled by default on most platforms.
You must set this option must if you want to also use
-XXallocRedoPrefetch
.
With this option, an additional chunk (that is, two chunks subsequent) is prefetched whenever a new chunk is used.
Note: | To fully benefit from this feature on Intel Xeon servers, you should disable hardware prefetching in the computer’s BIOS. |
Format: -XXallocRedoPrefetch[=true|false]
To enable: java -XXallocPrefetch
-XXallocRedoPrefetch
myApp
To disable: java -XXallocPerfetch
-XXallocRedoPrefetch=false
myApp
This feature is enabled by default on most platforms.
This option will not work unless
-XXallocPrefetch
is set.
This option enables the use of call profiling for code optimizations. Profiling records useful runtime statistics specific to the application and can—in many cases—increase performance because JVM can then act on those statistics.
Note: | This option is supported with the JRockit JVM R27.3.0 and later version. It may become default in future versions. |
java -XXcallProfiling myApp
This option is disabled by default. You must enable it to use it.
This option sets the compaction ratio. Compaction is the garbage collector’s main weapon against fragmentation. The idea is to look at a part of the heap and move all the live objects in that part together to create larger consecutive areas of free space. While the JVM is compacting the heap, all threads that want to access objects have to stand still because the JVM is moving the objects around. Consequently, only a part of the heap is compacted to reduce pause time.
In some cases, when the garbage collection time is too long it might be beneficial to reduce the compaction area to reduce the pause times. In some other cases, especially when you are allocating very large arrays, it may be necessary to increase the compaction area to reduce the fragmentation on the heap and thus make allocation faster.
Note: | Since JRockit JVM now employs dynamic compaction, -XXcompactRatio is rarely used anymore. |
Specify a ratio ([
nn
]
) of the compaction rate with a percentage size of the heap.
is set in a 500 MB heap, the garbage collector will compact 50 MB of the heap at each garbage/old collection.
If you are running a static compaction, the default is approximately 6%; however, if you are not using static compaction, the default applies only at the beginning of the run.
Use of - XXcompactRatio
will affect certain options, as described here:
-XXcompactRatio
while running -XgcPrio
:deterministic
or -XgcPrio: pausetime
might result in non-deterministic pause times.
-XXfullCompaction
is equivalent to -XXcompactRatio:100
and they will override each other.
-XXthroughputCompaction
as that might reduce the throughput
When using -XXcompactRatio
, be aware of the following exceptions:
-XXcompactRatio
together with
-XXnoCompaction
since this will disable compaction.-XXcompactRatio
,
-XXinternalCompactRatio
, and
-XXexternalCompactRatio
at the same time. Setting two of these options simultaneously is allowed.
This option sets the maximum number of references to objects in the compaction area.
Compaction is the process of moving live objects closer together in the Java heap to create larger free areas that can be used for allocation of large objects. The JRockit JVM compacts a small part of the Java heap at each garbage collection. The references to the objects in the compacted area are stored in a compact-set. When running non-deterministic garbage collection, the number of references to the compaction area will affect the compaction pause. This option can be used to limit the size of the compact-set and thus limit the compaction pause somewhat.
Format: -XXcompactSetLimit:
<size>
Enter the preferred compaction limit following the command.
java-XXcompactSetLimit:10000
myApp
sets the compaction limit to 10,000 references to objects in the compaction area.
By default the limit is a dynamic value. The default initial value depends on the garbage collector and release. Table 3-2 lists those defaults.
When using -XcompactSetLimit
, be aware of the following exceptions:
WARNING: | This is an advanced tuning option. You should only use it if you understand how it works and are prepared to accept the consequences of its misuse. |
This option sets the maximum number of references to any single object in the compaction area. If the number of references to an object exceeds this value, the object will not be moved during the compaction.
Compaction is the process of moving live objects closer together in the Java heap to create larger free areas that can be used for allocation of large objects. JRockit JVM compacts a small part of the Java heap at each garbage collection. When an object is moved during compaction, the references to that object must be updated. Moving an object with a lot of references to it is thus more costly than moving an object with only a few references to it.
Format: -XXcompactSetLimitPerObject:
<size>
java-XXcompactSetLimitPerObject:500
myApp
sets the compaction limit per object to 500 references.
This option can only be used if one of the following options is also set:
-XgcPrio
:deterministic
-XgcPrio:pausetime
-XXusePointerMatrix
This flag 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, thus improving performance. This option is also useful because it frees space on the heap that might not have been available had the references not been compressed.
Format: -XXcompressedRefs[=[true|1|false|0]]
java -XgcPrio:pausetime
-XXcompressedRefs=true
myApp
enables compressed references.
java -XgcPrio:pausetime
-XXcompressedRefs=0
myApp
disables compressed references.
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. This is typically controlled using the
-Xmx
flag.
Note: | In the JRockit JVM R26.4 and earlier, compressed references are disabled by default. |
Other command-line options are affected by -XXcompressedRefs
as described here:
-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.The following exceptions apply:
-XXcompressedRefs
option and specify a maximum heap size larger than the size supported by compressed references (more than 4 GB), the JVM throws an error and stops execution.
This 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, stayed 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. -XXdisableFatSpin
allows you to turn off spinning against a fat lock and eliminate the potential performance hit.
This option disables the garbage collector strategy changes. Compaction heuristics and nursery size heuristics are not affected by this option.
Format: -XXdisableGCHeuristics
By default, the garbage collection heuristics are enabled.
In releases prior to R27.5, this option requires that either
-XgcPrio
:throughput
or -XgcPrio:pausetime
is being used. It does not work with
-Xgc
or -XXsetGC
. Note that -XgcPrio:throughput
is default.
In the JRockit JVM R27.5 and later releases this option also disables temporary strategy changes to parallel mark or sweep in the static concurrent garbage collectors.
Usually when the JRockit JVM crashes it saves out the state of the process (called a core dump), but the heap is removed from this state since it is huge and would take up a lot of disk space. With this option we will save all the process state including the heap. More disk space will be used, but it makes it much easier for us 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. If you don’t want to save all the information that -XXdumpFullState
saves, use -XXdumpSize
:normal
.
-XXdumpFullState
is equivalent to -XXdumpsize:large.
For more information, see -XXdumpSize.
This option causes a dump file to be generated and allows you to specify the relative size of that file (that is, small, medium, or large).
Format: -XXdumpsize:
<File Size>
Use the command with one of the parameters listed in
Table 3-3 to specify the relative size of the dump file.
Includes everything that is in memory, including the Java heap. This option makes
-XXdumpSize equivalent to -XXdumpFullState.
|
This option makes JRockit JVM exit 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.
Enter this command at startup to force JRockit JVM to exit on the first occurrence of an out of memory error
This option sets the number of heap parts to compact during external compaction (also called “evacuation”).
Note: | You can change the total number of heap parts by using the command line option -XXheapParts. |
Format: -XXexternalCompactRatio=
nn
java
-XXexternalCompactRation=12
myApp
The default number of parts to compact is 8 for -XgcPrio
:throughput
, for all other garbage collection modes it is dynamic.
Using this option together with
-XgcPrio
or
-XXthroughputCompaction
disables parts of the dynamic compaction heuristics and can affect performance.
When using -XXexternalCompactRatio
, be aware of these exceptions:
-XXexternalCompactRatio
together with the following options:-XXcompactRatio
-XXinternalCompactRatio
-XXexternalCompactRatio
-XXfullCompaction
causes full compaction at all times, compacting the entire heap at each old collection. Compaction is the process of moving live objects closer together in the Java heap to create larger free areas that can be used for allocation of large objects. By default, the JRockit JVM compacts a small part of the Java heap at each garbage collection. Full compaction can increase the application throughput by minimizing the fragmentation of the heap but can also cause extremely long garbage collection pauses during the compaction.
Enter this command at startup to force full compaction. This is the only way to ensure that full compaction occurs.
When using -XXfullCompaction
, be aware of the following:
-XXfullCompaction
is the same as setting
-XXcompactRatio
:100.
-XXthroughputCompaction
as that might reduce the throughput.
You cannot use -XXfullCompaction
together with any of the following options:
This 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 doesn’t free enough memory; however, using it can cause longer garbage collection pauses.
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. -XXfullSystemGC
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.
Format: -XXgcthreads:<# threads>
java -XgcPrio:pausetime-XXgcThreads:4
myApp
sets “4” as the number of garbage collection threads the garbage collector can use during the parallel phases.
By default, these values are based on the number of cores and hardware threads on the machine.
This option is valid only from JRockit JDK 5.0 P26.0.0 and JRockit JDK 5.0 R26.4.0.
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 can’t 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 runtime to prevent the heap from becoming too full, this automatic tuning may 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 (unless -XXnoParSweep
has been specified). If this happens frequently and the garbage collection trigger doesn't increase automatically to prevent this, use -XXgcTrigge
r to manually increase the garbage collection trigger.
Where nn
is the amount of free heap, as a percentage of the heap, available when a garbage collections triggered.
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
isn’t specified, the system will try to automatically find a good percentage value. If -XXgcTrigger:
nn
is specified, it will be used instead and no automatic process is involved.
The garbage collector ignores the -XXgcTrigger
value when it runs both parallel mark and parallel sweep, for example if you specify -Xgc:singlepar
or -Xgc:genpar
on the command line.
This option sets the number of heap parts to a specified, static value.
The default number of heap parts is 128. The number of heap parts can increase during runtime.
The options -XXexternalCompactRatio and -XXinternalCompactRatio use heap parts as a unit. Changing the number of heap parts will thus affect how you should set these options.
This option uses hardware performance counters instead of software sampling in the HotSpot detector, which drives optimizations. The hardware performance counters gives higher accuracy for the hot spots sampling with better performance. This option is disabled b default.
This option is available with and supported on Itanium for Red Hat 4.0 and SuSE 9.0.
WARNING: | This is an advanced tuning option. You should only use it if you understand how it works and are prepared to accept the consequences of its misuse. |
This option sets the initial size of each “row” in the pointer matrix. The pointer matrix is a data structure used for storing references during compaction if -XgcPrio:deterministic or -XgcPrio
:
pausetime is used, or if -XXusePointerMatrix is set. Increasing the initial pointer vector size will increase the JRockit JVM’s memory footprint, but may in some cases increase the application throughput.
Format: -XXinitialPointerVectorSize:
<size>
java-XXinitialPointerVectorSize:40
myApp
sets the initial pointer vector size to 40 references.
This option works only when either -XgcPrio
:
deterministic
or -XgcPrio:
pausetime
are used or if -XXusePointerMatrix is set.
Sets the number of heap parts to compact during internal compaction.
Note: | The total number of heap parts can be changed with the command line option -XXheapParts. |
Format: -XXinternalCompactRatio=nn
java -XgcPrio:throughput
-XXinternalCompactRatio=12
myApp
Sets the number of heap parts to compact to 12. Note that, since -XgcPrio:throughput
is being used with this command, this overrides the default value of eight parts.
The default number of parts to compact is 8 for -XgcPrio
:throughput
, for all other garbage collection modes it is dynamic.
Using this option together with
-XgcPrio
or
-XXthroughputCompaction
disables parts of the dynamic compaction heuristics and can affect performance.
When using -XXinternalCompactRatio
, be aware of the following exceptions:
-XXinternalCompactRatio
together with the following options:
-XXcompactRatio
-XXinternalCompactRatio
-XXexternalCompactRatio
This option enables JRA recordings. A JRA recording is a way for you to get statistics on the JRockit JVM instance you are running.
Note: | This command was added beginning with JRockit JVM 1.4.2_04. Prior to that, a separate command was required for each permutation of the command, as described in Table 3-4. |
Format: Format is determined by your JRockit JVM version:
-XXjra
together with the parameters listed in the JRockit JVM 1.4.2_04 or Later in Table 3-4; for example:-XXjra:delay
-XXjraDelay
Allows you to set the maximum stack trace depth value in JRA recordings above the default of 16 frames.
|
||||
|
||||
java-XXjra:delay=10,recordingtime=100,filename=jrarecording2.xml
myApp
would result in a recording that:
To replicate this data with the JRA version released with the JRockit JVM 1.4.2_03 or older, you would need to enter the following four separate commands:
Do not add multiple -XXjra
options to the command line. If you do, all -XXjra
options except the final one will be discarded; for example, if you enter:
java -XXjra:filename=apa.jra -XXjra:delay=10 -XXjra:time=11 Hello
You get the same result as if you’d simply entered:
java -XXjra:time=11 Hello
This is because each time -XXjra
is parsed, the default values are reset, then the sub-arguments given to this argument are parsed and set. Instead, to get the result you expect from the first example, you should enter:
java -XXjra:filename=apa.jra,delay=10,time=11 Hello
This option sets the size of the keep area within the nursery as a percentage of the nursery. The keep area prevents newly allocated objects from being promoted to old space too early.
Note: | This option is only available in JRockit JVM R27.3 and later releases. |
Format: -XXkeepAreaRatio:
<percentage>
java-XXkeepAreaRatio:10
myApp
sets the keep area size to 10% of the nursery size.
By default the keep area is 25% of the nursery size. The keep area may not exceed 50% of the nursery size.
The keep area ratio is only valid when the garbage collector is generational.
This option sets a size for when an object is considered large (in terms of memory management). Objects larger than the limit are considered large and will not be allocated in TLAs. These are default limits that you can change by using the -XXlargeObjectLimit:nn
. These limits apply to JRockit JVM 1.4.2 and higher only.
Format: -XXlargeObjectLimit:
<size>
[k|K][m|M][g|G]
Combine the -XXlargeObjectLimit
with a memory value and unit (<value><unit>
).
java-XXlargeObjectLimit:6K
myApp
sets the large object limit to 6 kilobytes. There is no minimum or maximum large object limit.
If no value is specified, the default is set to whichever is the lower value of the minimum TLA size and the preferred TLA size divided by 2.
When you set the minimum and/or the preferred TLA size, the large object limit as well as the minimum block size (set with -XXminBlockSize) may be adjusted automatically by JRockit JVM if necessary. At all times, the following relations are maintained between minimum and preferred TLA size, large object limit, and minimum block size:
-XXlargeObjectLimit <= -XXtlaSize:min <= -XXminBlockSize
-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.
It is recommended to that you primarily set the TLA size parameters for memory management tuning purposes, while you let JRockit JVM automatically adjust the large object limit and minimum block size if necessary.
None
This an old option that tells JRockit JVM to use large pages, if they are available, for the Java heap and other areas in the JVM. Large pages allow your application to more effectively use the translation look-aside buffer (TLB) in the processor.
Note: | This is no longer the preferred option for enabling large pages. Instead, you should use -XlargePages. |
When -XXlazyUnlocking
is set, locks will not be 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 shared lock will convert to a normal lock and not stay in lazy mode.
java-XXlazyUnlocking
myApp
This example enables lazy unlocking in JRockit JVM R27.4 and older releases.
R27.5 Format: -XXlazyUnlocking:enable=<true|false>
java-XXlazyUnlocking:enable=false
myApp
This example disables lazy unlocking in JRockit JVM R27.5.
In R27.5 lazy unlocking is enabled by default in Java SE 6 versions of JRockit JVM on all platforms except IA64 and with all garbage collection modes except the deterministic garbage collection mode.
Lazy unlocking is disabled by default in older releases.
This option is intended for applications with many unshared locks. Be aware that it can introduce performance penalties with applications that have many short-lived but shared locks.
WARNING: | This is an advanced tuning option. You should only use it if you understand how it works and are prepared to accept the consequences of its misuse. |
This option sets the maximum limit for pooling large pointer vectors between garbage collections. The pointer vectors are rows in the “pointer matrix,” a data structure used for storing references during compaction if -XgcPrio:deterministic or -XgcPrio
:
pausetime is used, or if -XXusePointerMatrix is set. Increasing the maximum pooled pointer vector size will increase JRockit JVM’s memory footprint, but can, in some cases, increase the application throughput.
Format: -XXmaxPooledPointerVectorSize:
<size>
java-XXmaxPooledPointerVectorSize:8000
myApp
sets the maximum limit for pooling large pointer vectors to 8,000.
This option only has effect when -XgcPrio
:deterministic
or -Xgcprio:pausetime
is used, or if
-XXusePointerMatrix
is set.
This flag enables the mixed mode Java execution feature (MME). This feature is supported on 64-bit Intel Itanium Linux system. It allows user Java applications that contain 32-bit IA-32 JNI native code to run on an unmodified Intel Itanium platform.
To enable mixed mode Java execution, enter this:
java-XXmme
myApp
If -XXmme
is not specified, the mixed mode Java execution feature is disabled.
This feature is only available on 64-bit Intel Itanium systems. Currently, the only supported operating system is Red Hat Enterprise Linux 4 Update 4 with Intel IA-32 Execution Layer v6 or later installed.
-XXminblocksize
sets the minimum block size, which is the smallest memory area that will be returned to the freelist. Consequently, this option sets the smallest available chunk of memory on the freelists.
Note: | This option might not always be the best solution for setting a block size. In most instances, you will experience better results if you use -XXtlaSize. |
Format: -XXminBlockSize:
<memSize>
Where <memSize>
is the size of the memory area that will be returned to the freelist.
To speed up garbage collection and object allocation, the JVM ignores free chunks smaller than the minimum block size. Free chunks smaller than the minimum block size cannot be used for object allocation; these free chunks are called “dark matter.” Dark matter is wasted heap memory. Increasing the minimum block size will make allocation of large objects faster and may speed up garbage collection, but may also increase the amount of dark matter. An increased amount of dark matter will increase the number of garbage collections.
The default block size is 2 KB.
If two or more of
-XXlargeObjectLimit
,
-XXtlaSize
, and -XXminBlockSize
are set, they must have the following relationship:
-XXlargeObjectLimit <= -XXtlaSize <= -XXminBlockSize
If no value is specified, the default is set to whichever is the lower value of the minimum TLA size and the preferred TLA size divided by 2.
The large object limit (set with
-XXlargeObjectLimit
) as well as the minimum block size may be adjusted automatically by JRockit JVM if you set the minimum and/or the preferred TLA size,
At all times, the following relations are maintained between minimum and preferred TLA size, large object limit, and minimum block size:
-XXlargeObjectLimit <= -XXtlaSize:min <= -XXminBlockSize
-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.
It is recommended to that you primarily set the TLA size parameters for memory management tuning purposes, while you let JRockit JVM automatically adjust the large object limit and minimum block size if necessary.
None.
Disables compaction during garbage collection. Compaction is the process of moving live objects closer together in the Java heap to create larger free areas that can be used for allocation of large objects. Disabling compaction may reduce garbage collection pause times, but may also lead to fragmentation in the Java heap and thus lower the application throughput or in the worst case cause an OutOfMemoryError to be thrown.
During every garbage collection, at least a partial compaction is done. If you prefer no compaction, assuming the application can survive without it, you must use this command at startup to disable it.
You cannot use the following options if compaction is disabled:
This option turns off JIT inlining through JRockit JVM. “JIT inlining” inlines calls to small methods as soon as they are encountered in the code pipeline.
Note: | Using this option will cause a small performance penalty. |
You should only use this option in combination with
-XnoOpt
. -XXnojitinline
only disables inlining the first time a method is compiled. Unless you set -XnoOpt
as well, methods can still be inlined when code is optimized.
This option prevents a call to System.gc() from starting a garbage collection. If your application uses
System.gc()
and you want to the garbage collector itself to decide when to run the collection (default behavior), you should use this option. This option is useful in some debugging situations and might also enhance performance as it prevents unnecessary garbage collection from happening.
Simply 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.
This option will also cause -XXprintSystemGC to print out different information than if this option is not used.
You cannot use -XXnoSystemGC
together with -XXfullSystemGC
.
This option tells the JVM how many threads to use for the optimizing methods. The work of optimizing methods run in the background.
Format: -XXoptThreads:<# threads>
Enter this option at the command line.
java -XgcPrio:pausetime-XXoptThreads:3
myApp
tells the JVM to use three threads for the optimizing methods.
If -XXoptThreads
is not specified, one thread is used for the optimizing methods.
This option is valild only from JRockit JVM 5.0 P26.0.0 and JRockit JVM 5.0 R26.4.0.
WARNING: | This is an advanced tuning option. You should only use it if you understand how it works and are prepared to accept the consequences of its misuse. |
This option sets the linear seek distance in the pointer matrix. The pointer matrix is a data structure used for storing references during compaction if -XgcPrio:deterministic or -XgcPrio
:
pausetime is used, or if -XXusePointerMatrix is set. Decreasing the linear seek distance increases JRockit JVM's memory footprint, but can, in some cases, increase the application throughput.
Format: -XXpointerMatrixLinearSeekDistance:
<distance>
java -XXpointerMatrixLinearSeekDistance:5 myApp
sets the linear seek distance to 5
This option works only when -XgcPrio
:
deterministic
or -XgcPrio
:
pausetime
is used, or if -XXusePointerMatrix
is set.
This option causes printing of the thread ID of the thread requesting the garbage collection. This option provides information about the frequency with which System.gc()
is invoked. The printout is different if using -XXnoSystemGC. With that option, the thread ID is not printed; instead, the only information appearing indicates that System.gc()
was called but the request was denied.
Entering this option as shown above causes the threadID to be printed out whenever System.gc()
is invoked.
This option turns off the dynamic garbage collector and sets the static garbage collector of your choice. Applications with static behavior and work load might benefit from having a static garbage collector instead of a dynamic one. In such cases this option would be beneficial. This option offers more garbage collector mode selections than
-Xgc
.
Format: -XXsetGC:[gen/single|par/con|par/con]
myApp
You can choose a garbage collector that is either generational or single spaced with a parallel or a concurrent mark and uses either a parallel sweep or a concurrent sweep.
During a two-generational garbage collection, the heap is divided into two sections: an old generation and a young generation—also called the “nursery.” Objects are allocated in the nursery and when it is full, the JVM stops all Java threads and moves the live objects from the nursery, young generation, to the old generation.
The single-spaced option of garbage collection means that all objects live out their lives in a single space on the heap, regardless of their age. In other words, a single-spaced garbage collector does not have a nursery.
The concurrent garbage collection algorithm does its marking and sweeping “concurrently” with all other processing; that is, it does not stop Java threads to do the complete garbage collection.
The parallel garbage collection algorithm stops Java threads when the heap is full and uses every CPU to perform a complete mark and sweep of the entire heap. A parallel garbage collector can have longer pause times than concurrent garbage collectors, but it maximizes application throughput. Even on single CPU machines, this maximized performance makes parallel the recommended garbage collector, provided that your application can tolerate the longer pause times.
java
-XXsetGC:genparcon
myApp
sets the garbage collection option to generational (two-spaced) with a parallel mark algorithm and a concurrent sweep algorithm.
java
-XXsetGC:singleconpar
myApp
sets the garbage collection option to single-spaced with a concurrent mark algorithm and a parallel sweep algorithm.
WARNING: | Use this option only if you know the different effects of different garbage collection strategies. The garbage collector modes offered by
-Xgc are sufficient for most applications. |
When you specify -XXsetGC
, the following options are affected:
-XXsetGC
will override
-Xgc
and vice versa-XsetGC
will override part of the effect of -server
and -client
.
When using -XXsetGC
, be aware of the following exceptions:
This option sets a static compact ratio and simple “sliding window” heuristics for compaction area choice.
Compaction is the process of moving live objects closer together in the Java heap to create larger free areas that can be used for allocation of large objects. JRockit JVM uses partial compaction, where only a small part of the Java heap is compacted each garbage collection. The default heuristics for choosing the compaction area size and position aim at keeping the compaction pause times even. If the application isn't sensitive to pausetimes, a static compaction area size and simple “sliding window” compaction area choice may increase performance.
Compaction occurs in a “sliding window” scheme, meaning that only part of the heap is compacted during each garbage collection. How much of the heap that is compacted each time can be specified using -XXcompactRatio
. By default about 6%, or 8/128, of the heap is compacted each time. This means that in the first garbage collection parts 1-8 are compacted, in the second, parts 9-16 are compacted, and so on. After compacting parts 120-128 the “window” starts over at part 1-8. The compaction type for static mode is external (evacuation).
You can use -XXcompactRatio to specify the size of the compaction area.
When using -XstaticCompaction
, be aware of the following exceptions:
This option adjusts the compaction ratio dynamically, based upon the ratio of live data in the heap. This option can improve application throughput for applications with a high allocation rate but low ratio of live data.
Format: -XXthroughputCompaction
Enter this option at the command line.
When using -XXthroughputCompaction
, be aware of the following:
-XXfullCompaction
,
-XXcompactRatio
,
-XXinternalCompactRatio
, or
-XXexternalCompactRatio
as these options limit the compaction ratio in other ways. :pausetime
, -Xgcprio:deterministic
, or -XpauseTarget the pausetimes may become too long and non-deterministic.
When using -XXthroughputCompaction
, be aware of these exceptions:
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 may affect performance.
Format: -XXtlaSize:
<param>=
<size>[k|K][m|M][g|G]
Where <param>
is one of the parameters listed in Table 3-5.
There are no upper or lower limits to -XXtlaSize
. The default value is 2KB.
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.
-XXtlasize:min=2k,preferred=16k
sets the default for large heaps.
-XXtlasize:min=8k,preferred=512k
set a TLA size suitable for heaps of several GB.
Note: | The old style of setting TLA size (that is, -XXtlasize=256k ) is still supported but has been deprecated. If you use the old style, JRockit JVM will interpret the option as if the fixed parameter was used; for example, -XXtlasize=256k would be interpreted as -XXtlasize:fixed=256k . |
The default value for the minimum size is 2 kB. The minimum value cannot be lower than the large object limit. If the large object limit is explicitly set higher than the minimum TLA size (with -XXlargeObjectLimit), then the minimum TLA size will be raised to match the large object limit.
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-6 lists the default sizes for the different configurations.
When you set the minimum and/or the preferred TLA size, the large object limit (set with -XXlargeObjectLimit) and the minimum block size (set with -XXminBlockSize) may be adjusted automatically by JRockit JVM if necessary. At all times, the following relations are maintained between minimum and preferred TLA size, large object limit, and minimum block size:
-XXlargeObjectLimit <= -XXtlaSize:min <= -XXminBlockSize
-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 large object limit will be set to whichever is the lower value of the minimum TLA size and the preferred TLA size divided by 2. The default minimum block size is 2k.
It is recommended to that you primarily set the TLA size parameters for memory management tuning purposes, while you let JRockit JVM automatically adjust the large object limit and minimum block size if necessary.
This option enables the trace scheduler framework (TSF) on 64-bit Intel Itanium systems.
Note: | This option replaces the -Djrockit.codegen.tracesched=<true|false> argument available in previous releases of the JRockit JVM. |
To enable the trace scheduler framework, enter:
java-Xtsf=true
myApp
The following line will be logged when TSF is enabled:
[INFO ] Trace scheduling is enabled.
If -XXtsf=
is not specified or if it is set to false
, the trace scheduler framework feature is disabled.
This feature is only available on 64-bit Intel Itanium systems.
WARNING: | This is an advanced tuning option. You should only use it if you understand how it works and are prepared to accept the consequences of its misuse. |
This option indicates that the pointer matrix should be used instead of the pointerset. The pointer matrix is default when running -Xgcprio:deterministic
or -Xgcprio:pausetime
.
java
-XXusePointerMatrix
myApp
You should not use this option together with -XgcPrio:throughput
, as it alters or disables many of the throughput-specific compaction heuristics.
You cannot use this option together with -XXcompactSetLimit
.
Format: -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, you will get an error message.
java
-XX:MaximumNurseryPercentage=80
myApp
You cannot use this option with a single-spaced (non-generational) garbage collector. The option can be used both with a static generational garbage collector or with dynamic garbage collection.
This option enables a new, faster hash function for HashMap that was introduced in Java 5.0 Update 8 and is part of the JRockit JVM as of R27.1.0. This hash function can improve performance through improved hash spread, but changes the order in which elements are stored in the HashMap. For compatibility reasons, JRockit JVM 5.0 uses the old hash function by default unless started with -XXaggressive
.
Note: | This flag is supported as of JRockit JVM 5.0 R27.1. It is not available in JRockit JVM 1.4.2. |
Format: -X:[+|-]useNewHashFunction
This option uses Sun’s 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.
-XX:+UseNewHashFunction
Explicitly enables the new hash function.
-XX:-UseNewHashFunction
Explicitly disables the new hash function.
The new hash function is disabled by default in the JRockit JVM 5.0.
-XXaggressive
enables use of the new hash function unless it is explictly disabled using -XX:-UseNewHashFunction
.
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.
WARNING: | This feature is experimental and not supported by Oracle at this time. Improper use can cause serious performance issues. |
Format: -XX:[+|-]UseThreadPriorities
This option uses Sun’s 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 use of java.lang.Thread.setPriority()
and related APIs.
Explicitly enables use of the APIs.
Explicitly disables use of the APIs.
-XX:-UseThreadPriorities
. Thread priorities are disabled by default.
Availability of this option is determined by the platform you are running on.
This option enables caching of commonly allocated strings. This option was introduced in Oracle JRockit 6 as of P28.0.0. It is not available in JRockit JVM 1.4.2 or 1.5.0.
Format: -X:[+|-]useStringCache
This option uses Sun’s 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 string cache.
Explicitly enables the string cache.
Explicitly disables the string cache.
The string cache is disabled by default.