Command Line Reference

-XX Command-line Options

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.

-XXaggressive

-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.

Operation

Format: -XXaggressive:<param>

Combine -XXaggressive with one of the parameters listed in Table 3-1

For Example:

java -XXaggressive:opt myApp

By specifying -XXagressive with the opt parameter, adaptive optimizations will be scheduled earlier in runtime and new optimizations will be enabled.

Default Value

If neither opt nor memory is specified, the application will run as if both were specified.

Flags or Options Affected

This option will set several things, which can be reset or changed by adding the explicit options on the command line after -XXaggressive.

Exceptions

None

-XXallocClearChunks

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.

Operation

Format: -XXallocClearChunks

or:

-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.

Default Value

By default, this mechanism is disabled. If you use this option but do not specify a boolean value, the default is true.

Flags or Other Options Affected

None

Exceptions

While this mechanism is, by default, disabled, it is included in aggressive:memory on IA64 systems.

-XXallocClearChunkSize

When used with -XXallocClearChunkSize, this option sets the size of the chunks to be cleared.

Operation

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

For Example:

java -XXallocClearChunks -XXallocClearChunkSize=256m myApp

Default Value

If this option is used but no value is specified, the default is 512 bytes.

Flags or Other Options Affected

See Operation for a description of how this option works with -XXallocClearChunks.

Exceptions

This option cannot be used unless -XXallocClearChunks is also used.

-XXallocPrefetch

With this option a thread-local area is split into chunks and, when a new chunk is reached, the subsequent chunk is prefetched.

Operation

Format: -XXallocPrefetch[=true|false]

For Example:

To enable: java -XgcPrio:pausetime -XXallocPrefetch myApp

To disable: java -XgcPrio:pausetime -XXallocPrefetch=false myApp

Default Value

This feature is enabled by default on most platforms.

Other Flags and Options Affected

You must set this option must if you want to also use -XXallocRedoPrefetch.

Exceptions

None

-XXallocRedoPrefetch

With this option, an additional chunk (that is, two chunks subsequent) is prefetched whenever a new chunk is used.

Operation

Format: -XXallocRedoPrefetch[=true|false]

For Example:

To enable: java -XXallocPrefetch -XXallocRedoPrefetch myApp

To disable: java -XXallocPerfetch -XXallocRedoPrefetch=false myApp

Default Value

This feature is enabled by default on most platforms.

Other Flags and Options Affected

None

Exceptions

This option will not work unless -XXallocPrefetch is set.

-XXcallProfiling

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.

Operation

Format: -XXcallProfiling

For Example:

java -XXcallProfiling myApp

Default Value

This option is disabled by default. You must enable it to use it.

Other Flags and Options Affected

None

Exceptions

None

-XXcompactRatio

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.

Operation

Format: -XXcompactRatio:<nn>

Specify a ratio ([nn]) of the compaction rate with a percentage size of the heap.

For Example:

If

java -XXcompactRatio:10 myApp

is set in a 500 MB heap, the garbage collector will compact 50 MB of the heap at each garbage/old collection.

Default Value

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.

Flags or Other Options Affected

Use of - XXcompactRatio will affect certain options, as described here:

Exceptions

When using -XXcompactRatio, be aware of the following exceptions:

-XXcompactSetLimit

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.

Operation

Format: -XXcompactSetLimit:<size>

Enter the preferred compaction limit following the command.

For Example:

java -XXcompactSetLimit:10000 myApp

sets the compaction limit to 10,000 references to objects in the compaction area.

Default Values

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.

Flags or Other Options Affected

None

Exceptions

When using -XcompactSetLimit, be aware of the following exceptions:

-XXcompactSetLimitPerObject

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.

Operation

Format: -XXcompactSetLimitPerObject:<size>

For example:

java -XXcompactSetLimitPerObject:500 myApp

sets the compaction limit per object to 500 references.

Default Value

The default value is 100

Flags or Other Options Affected

None

Exceptions

This option can only be used if one of the following options is also set:

-XXcompressedRefs

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.

Operation

Format: -XXcompressedRefs[=[true|1|false|0]]

For Example:

java -XgcPrio:pausetime -XXcompressedRefs=true myApp

enables compressed references.

or

java -XgcPrio:pausetime -XXcompressedRefs=0 myApp

disables compressed references.

Default Value

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.

Flags or Other Options Affected

Other command-line options are affected by -XXcompressedRefs as described here:

Exceptions

The following exceptions apply:

-XXdisableFatSpin

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.

Operation

Format: -XXdisableFatSpin

Flags or Other Options Affected

None

Exceptions

None

-XXdisableGCHeuristics

This option disables the garbage collector strategy changes. Compaction heuristics and nursery size heuristics are not affected by this option.

Operation

Format: -XXdisableGCHeuristics

Default Value

By default, the garbage collection heuristics are enabled.

Flags or Other Options Affected

None

Exceptions

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.

-XXdumpFullState

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.

This option is the default.

Operation

Format: -XXdumpFullState

Flags or Other Options Affected

-XXdumpFullState is equivalent to -XXdumpsize:large. For more information, see -XXdumpSize.

Exceptions

None

-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).

Operation

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.

Flags or Other Options Affected

None

Exceptions

None

-XXexitOnOutOfMemory

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.

Operation

Format: -XXexitOnOutOfMemory

Enter this command at startup to force JRockit JVM to exit on the first occurrence of an out of memory error

Flags or Other Options Affected

None

Exceptions

None

-XXexternalCompactRatio

This option sets the number of heap parts to compact during external compaction (also called “evacuation”).

Operation

Format: -XXexternalCompactRatio=nn

For Example:

java -XXexternalCompactRation=12 myApp

Default Value

The default number of parts to compact is 8 for -XgcPrio:throughput, for all other garbage collection modes it is dynamic.

Flags or Other Options Affected

Using this option together with -XgcPrio or -XXthroughputCompaction disables parts of the dynamic compaction heuristics and can affect performance.

Exceptions

When using -XXexternalCompactRatio, be aware of these exceptions:

-XXfullCompaction

-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.

Operation

Format: -XXfullCompaction

Enter this command at startup to force full compaction. This is the only way to ensure that full compaction occurs.

Flags or Other Options Affected

When using -XXfullCompaction, be aware of the following:

Exceptions

You cannot use -XXfullCompaction together with any of the following options:

-XXfullSystemGC

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.

Operation

Format: -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. -XXfullSystemGC frees all softly referenced objects.

Flags or Other Options Affected

None

Exceptions

You cannot use -XXfullSystemGC together with -XXnoSystemGC.

-XXgcThreads

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.

Operation

Format: -XXgcthreads:<# threads>

For Example:

java -XgcPrio:pausetime -XXgcThreads:4 myApp

sets “4” as the number of garbage collection threads the garbage collector can use during the parallel phases.

Default Value

By default, these values are based on the number of cores and hardware threads on the machine.

Flags and Other Options Affected

None

Exceptions

This option is valid only from JRockit JDK 5.0 P26.0.0 and JRockit JDK 5.0 R26.4.0.

-XXgcTrigger

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 -XXgcTrigger to manually increase the garbage collection trigger.

Operation

Format: -XXgcTrigger:nn

Where nn is the amount of free heap, as a percentage of the heap, available when a garbage collections triggered.

For example:

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.

Default Value

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.

Other Flags and Options Affected

None

Exceptions

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.

-XXheapParts

This option sets the number of heap parts to a specified, static value.

Operation

Format: -XXheapParts=nn

For Example:

java -XXheapParts=64 myApp

Default Value

The default number of heap parts is 128. The number of heap parts can increase during runtime.

Flags or Other Options Affected

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.

Exceptions

None

-XXhpm

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.

Operation

Format: -XXhpm

Other Flags Affected

None

Exceptions

This option is available with and supported on Itanium for Red Hat 4.0 and SuSE 9.0.

-XXinitialPointerVectorSize

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.

Operation

Format: -XXinitialPointerVectorSize:<size>

For Example:

java -XXinitialPointerVectorSize:40 myApp

sets the initial pointer vector size to 40 references.

Default Value

The default value is 20

Flags or Other Options Affected

None

Exceptions

This option works only when either -XgcPrio: deterministic or -XgcPrio: pausetime are used or if -XXusePointerMatrix is set.

-XXinternalCompactRatio

Sets the number of heap parts to compact during internal compaction.

Operation

Format: -XXinternalCompactRatio=nn

For Example:

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.

Default Value

The default number of parts to compact is 8 for -XgcPrio:throughput, for all other garbage collection modes it is dynamic.

Flags or Other Options Affected

Using this option together with -XgcPrio or -XXthroughputCompaction disables parts of the dynamic compaction heuristics and can affect performance.

Exceptions

When using -XXinternalCompactRatio, be aware of the following exceptions:

-XXjra

This option enables JRA recordings. A JRA recording is a way for you to get statistics on the JRockit JVM instance you are running.

Operation

Format: Format is determined by your JRockit JVM version:

For Example:

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:

Avoid Using Multiple Options

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

Flags or Other Options Affected

None

Exceptions

None

-XXkeepAreaRatio

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.

Operation

Format: -XXkeepAreaRatio:<percentage>

For Example:

java -XXkeepAreaRatio:10 myApp

sets the keep area size to 10% of the nursery size.

Default Value

By default the keep area is 25% of the nursery size. The keep area may not exceed 50% of the nursery size.

Flags or Other Options Affected

None

Exceptions

The keep area ratio is only valid when the garbage collector is generational.

-XXlargeObjectLimit

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.

Operation

Format: -XXlargeObjectLimit:<size>[k|K][m|M][g|G]

Combine the -XXlargeObjectLimit with a memory value and unit (<value><unit>).

For Example:

java -XXlargeObjectLimit:6K myApp

sets the large object limit to 6 kilobytes. There is no minimum or maximum large object limit.

Default Value

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.

Flags or Other Options Affected

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.

Exceptions

None

-XXlargePages

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.

-XXlazyUnlocking

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.

Operation

Format: -XXlazyUnlocking

For Example:

java -XXlazyUnlocking myApp

This example enables lazy unlocking in JRockit JVM R27.4 and older releases.

R27.5 Format: -XXlazyUnlocking:enable=<true|false>

For Example:

java -XXlazyUnlocking:enable=false myApp

This example disables lazy unlocking in JRockit JVM R27.5.

Default Value

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.

Other Flags and Options Affected

None

Exceptions

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.

-XXmaxPooledPointerVectorSize

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.

Operation

Format: -XXmaxPooledPointerVectorSize:<size>

For Example:

java -XXmaxPooledPointerVectorSize:8000 myApp

sets the maximum limit for pooling large pointer vectors to 8,000.

Default Value

The default value is 5120

Flags or Other Options Affected

None

Exceptions

This option only has effect when -XgcPrio:deterministic or -Xgcprio:pausetime is used, or if -XXusePointerMatrix is set.

-XXmme

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.

Operation

Format: -XXmme

To enable mixed mode Java execution, enter this:

java -XXmme myApp

Default Value

If -XXmme is not specified, the mixed mode Java execution feature is disabled.

Flags or Other Options Affected

None

Exceptions

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

-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.

Operation

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.

Default Value

The default block size is 2 KB.

Flags or Other Options Affected

None

Exceptions

If two or more of -XXlargeObjectLimit, -XXtlaSize, and -XXminBlockSize are set, they must have the following relationship:

-XXlargeObjectLimit <= -XXtlaSize <= -XXminBlockSize

Default Value

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.

Flags or Other Options Affected

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.

Exceptions

None.

-XXnoCompaction

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.

Operation

Format: -XXnocompaction

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.

Flags or Other Options Affected

None

Exceptions

You cannot use the following options if compaction is disabled:

-XXnoJITInline

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.

Operation

Format: -XXnoJITInline

Flags and Other Options Affected

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.

Exceptions

None

-XXnoSystemGC

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.

Operation

Format: -XXnoSystemGC

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.

Flags or Other Options Affected

This option will also cause -XXprintSystemGC to print out different information than if this option is not used.

Exceptions

You cannot use -XXnoSystemGC together with -XXfullSystemGC.

-XXoptThreads

This option tells the JVM how many threads to use for the optimizing methods. The work of optimizing methods run in the background.

Operation

Format: -XXoptThreads:<# threads>

Enter this option at the command line.

For Example:

java -XgcPrio:pausetime -XXoptThreads:3 myApp

tells the JVM to use three threads for the optimizing methods.

Default Value

If -XXoptThreads is not specified, one thread is used for the optimizing methods.

Other Options or Flags Affected

None

Exceptions

This option is valild only from JRockit JVM 5.0 P26.0.0 and JRockit JVM 5.0 R26.4.0.

-XXpointerMatrixLinearSeekDistance

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.

Operation

Format: -XXpointerMatrixLinearSeekDistance:<distance>

For Example:

java -XXpointerMatrixLinearSeekDistance:5 myApp

sets the linear seek distance to 5

Default Value

The default value is 10

Flags or Other Options Affected

None

Exceptions

This option works only when -XgcPrio:deterministic or -XgcPrio:pausetime is used, or if -XXusePointerMatrix is set.

-XXprintSystemGC

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.

Operation

Format: -XXprintSystemGC

Entering this option as shown above causes the threadID to be printed out whenever System.gc() is invoked.

Flags or Other Options Affected

None

Exceptions

None

-XXsetGC

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 .

Operation

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.

For Example:

The command:

java -XXsetGC:genparcon myApp

sets the garbage collection option to generational (two-spaced) with a parallel mark algorithm and a concurrent sweep algorithm.

The command:

java -XXsetGC:singleconpar myApp

sets the garbage collection option to single-spaced with a concurrent mark algorithm and a parallel sweep algorithm.

Flags or Other Options Affected

When you specify -XXsetGC, the following options are affected:

Exceptions

When using -XXsetGC, be aware of the following exceptions:

-XXstaticCompaction

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.

Operation

Format: -XXstaticCompaction

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).

For Example:

Flags or Other Options Affected

You can use -XXcompactRatio to specify the size of the compaction area.

Exceptions

When using -XstaticCompaction, be aware of the following exceptions:

-XXthroughputCompaction

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.

Operation

Format: -XXthroughputCompaction

Enter this option at the command line.

Other Flags or Options Affected

When using -XXthroughputCompaction, be aware of the following:

Exceptions

When using -XXthroughputCompaction, be aware of these exceptions:

-XXtlaSize

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.

Operation

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.

For example:

-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.

Default Value

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.

Flags or Other Options Affected

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.

Exceptions

None.

-XXtsf

This option enables the trace scheduler framework (TSF) on 64-bit Intel Itanium systems.

Operation

Format: -XXtsf=<true|false>

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.

Default Value

If -XXtsf= is not specified or if it is set to false, the trace scheduler framework feature is disabled.

Flags or Other Options Affected

None

Exceptions

This feature is only available on 64-bit Intel Itanium systems.

-XXusePointerMatrix

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.

Operation

Format: -XXusePointerMatrix

For Example:

java -XXusePointerMatrix myApp

Flags or Other Options Affected

You should not use this option together with -XgcPrio:throughput, as it alters or disables many of the throughput-specific compaction heuristics.

Exceptions

You cannot use this option together with -XXcompactSetLimit.

-XX:MaximumNurseryPercentage

Operation

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.

For Example:

java -XX:MaximumNurseryPercentage=80 myApp

Default Value

The default value is 95.

Exceptions

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.

-XX:(+|-)UseNewHashFunction

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.

Operation

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.

For Example:

-XX:+UseNewHashFunction

Explicitly enables the new hash function.

-XX:-UseNewHashFunction

Explicitly disables the new hash function.

Default Value

The new hash function is disabled by default in the JRockit JVM 5.0.

Flags or Other Options Affected

-XXaggressive enables use of the new hash function unless it is explictly disabled using -XX:-UseNewHashFunction.

Exceptions

None

-XX:(+|-)UseThreadPriorities

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.

Operation

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.

For example:

-XX:+UseThreadPriorities

Explicitly enables use of the APIs.

-XX:-UseThreadPriorities

Explicitly disables use of the APIs.

Default Value

-XX:-UseThreadPriorities. Thread priorities are disabled by default.

Flags or Other Options Affected

None

Exceptions

Availability of this option is determined by the platform you are running on.

-XX:(+|-)UseStringCache

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.

Operation

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.

For Example:

-XX:+UseStringCache

Explicitly enables the string cache.

-XX:-UseStringCache

Explicitly disables the string cache.

Default Value

The string cache is disabled by default.

Flags or Other Options Affected

None

Exceptions

None