-client
Specifies that the HotSpot VM should optimize for client applications. At the present time, this option results in the use of the client JVM as the runtime environment. This command line option should be used when application startup time and small memory footprint are the most important performance criteria for the application, much more important than high throughput.
-server
Specifies that the HotSpot VM should optimize for server applications. At the present time, this option results in the use of the server JVM as the runtime environment. This command line option should be used when high application throughput is more important than startup time and small memory footprint.
-d64
Loads the 64-bit HotSpot VM instead of the default HotSpot 32-bit VM. This command line option should be used when there is a need to use a larger Java heap size than is possible with a 32-bit HotSpot VM. -XX:+UseCompressedOops should also be used in conjunction with this command line option for -Xmx and -Xms values less than 32 gigabytes. HotSpot versions later than Java 6 Update 18 enable -XX:+UseCompressedOops by default.
-XX:+UseCompressedOops
Enables a feature called compressed oops. Oops stands for ordinary object pointer, which is the means by which the HotSpot VM represents a reference to a Java object internally. 64-bit JVMs come with a performance penalty due to an increase in the size of Java references from 32 bits to 64 bits. This increase in width results in fewer ordinary object pointers being available on a CPU cache line, and as a result decreases CPU cache efficiency. The decrease in CPU cache efficiency on 64-bit JVMs often results in about an 8% to 20% performance degradation compared to a 32-bit JVM.
-XX:+UseCompressedOops can yield 32-bit JVM performance with the benefit of larger 64-bit JVM heaps. Some Java applications realize better performance with a 64-bit HotSpot VM using compressed oops than with a 32-bit HotSpot VM. The performance improvement realized from compressed oops arises from being able to transform a 64-bit pointer into a 32-bit offset from a Java heap base address. Useful when you want a Java heap larger than what can be specified for a 32-bit HotSpot VM but are not willing to sacrifice 32-bit VM performance. It should be used when specifying a Java heap up to 32 gigabytes (-Xmx32g), though best performance is realized up to about 26 gigabytes (-Xmx26g).
-Xms<n>[g|m|k]
The initial and minimum size of the Java heap, which includes the total size of the young generation space and old generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The Java heap will never be smaller than the value specified for -Xms. When -Xms is smaller than -Xmx, the size of Java heap may grow or contract depending on the needs of the application. However, growing or contracting the Java heap requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -Xms and -Xmx to the same value.
-Xmx<n>[g|m|k]
The maximum size of the Java heap, which includes the total size of the young generation space and old generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The Java heap will never grow to more than the value specified for -Xmx.
When -Xmx is larger than -Xms, the size of Java heap may grow or contract depending on the needs of the application. However, growing or contracting the Java heap requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -Xms and -Xmx to the same value.
-XX:NewSize=<n>[g|m|k]
The initial and minimum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space will never be smaller than the value specified. When -XX:NewSize is smaller than -XX:MaxNewSize, the size of the young generation space may grow or contract depending on the needs of the application. However, growing or contracting the young generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:NewSize and -XX:MaxNewSize to the same value.
-XX:MaxNewSize=<n>[g|m|k]
The maximum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space will never be larger than the value specified. When -XX:MaxNewSize is larger than -XX:NewSize, the size of the young generation space may grow or contract depending on the needs of the application. However, growing or contracting the young generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:MaxNewSize and -XX:NewSize to the same value.
-Xmn<n>[g|m|k]
Sets the initial, minimum, and maximum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space size will be set to the value specified.A convenient shortcut command line option to use when it is desirable to set -XX:NewSize and -XX:MaxNewSize to the same value.
-XX:NewRatio=<n>
The ratio between the young generation space size and old generation space size. For example, if n is 3, then the ratio is 1:3, and the young generation space size is onefourth of the total size of young generation space and old generation space. The ratio of the sizes of both young generation space and old generation space are maintained if the Java heap grows or contracts.A convenient command line option when -Xms and -Xmx are different sizes and there is a desire to maintain the same ratio of space between young generation space and old generation space.
-XX:PermSize=<n>[g|m|k]
The initial and minimum size of the permanent generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The permanent generation space will never be smaller than the value specified. When -XX:PermSize is smaller than -XX:MaxPermSize, the size of the permanent generation space may grow or contract depending on the needs of the application, in particular the need to load classes or store interned Strings. However, growing or contracting the permanent generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:PermSize and -XX:MaxPermSize to the same value.
-XX:MaxPermSize=<n>[g|m|k]
The maximum size of the permanent generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The permanent generation space will never be larger than the value specified. When -XX:MaxPermSize is larger than -XX:PermSize, the size of the permanent generation space may grow or contract depending on the needs of the application, in particular the need to load classes or store interned Strings. However, growing or contracting the permanent generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:PermSize and -XX:MaxPermSize to the same value.
-XX:SurvivorRatio=<n>
The ratio of the size of each survivor space to the eden space size, where <n> is the ratio. The following equation can be used to determine the survivor space size for a ratio specified with -XX:SurvivorRatio=<n>: survivor size = -Xmn<n>/(-XX:SurvivorRatio=<n> + 2)where -Xmn<n> is the size of the young generation space and -XX:SurvivorRatio=<n> is the value specified as the ratio. The reason for the + 2 in the equation is there are two survivor spaces. The larger the value specified as the ratio, the smaller the survivor space size. -XX:SurvivorRatio=<n> should be used when you want to explicitly size survivor spaces to manipulate object aging with the concurrent garbage collector, or to manipulate object aging with the throughput garbage collector when adaptive sizing is disabled using the command line option -XX:-UseAdaptiveSizePolicy.
-XX:SurvivorRatio=<n> should not be used with the throughput collector with adaptive sizing enabled. By default adaptive sizing is enabled with the throughput garbage collector by -XX:+UseParallelGC or -XX:+UseParallelOldGC. If an initial survivor ratio is desired for the throughput garbage collector’s adaptive sizing to begin with, then -XX:InitialSurvivorRatio=<n> should be used.
-XX:InitialSurvivorRatio=<n>
The initial survivor space ratio to use with the throughput garbage collector, where <n> is the ratio. It is only the initial survivor space ratio. This command line option is intended to be used with the throughput garbage collector with adaptive sizing enabled. Adaptive sizing resizes survivor spaces as the application behavior warrants. The following equation can be used to determine the initial survivor space size for a ratio specified with -XX:InitialSurvivorRatio=<n>: initial survivor size = -Xmn<n>/(-XX:InitialSurvivorRatio=<n> + 2)where -Xmn<n> is the size of the young generation space and -XX:Initial SurvivorRatio=<n> is the value specified as the ratio. The reason for the + 2 in the equation is there are two survivor spaces. The larger the value specified as the initial ratio, the smaller the initial survivor space size.
-XX:InitialSurvivorRatio=<n> should be used with the throughput collector with adaptive sizing enabled when there is a desire to specifically initially size survivor spaces. By default, adaptive sizing is enabled with the throughput garbage collector using -XX:+UseParallelGC or -XX:+UseParallelOldGC. If adaptive sizing is disabled, or the concurrent collector is in use, the -XX:SurvivorRatio=<n> command line option should be used when you want to explicitly size survivor spaces to manipulate object aging for the entire execution of the application.
-XX:TargetSurvivorRatio=<percent>
The survivor space occupancy the HotSpot VM should attempt to target after a minor garbage collection. The value to specify is a percentage of the size of a survivor space, rather than a ratio. Its default value is 50%.
Tuning the target survivor occupancy is rarely required. Through extensive testing of a vast variety of different types of application workloads by the HotSpot VM engineering team, a 50% target survivor space occupancy tends to work best for most applications since it helps deal with spikes in surviving objects seen at minor garbage collections in many disparate types of Java applications. If the application being fine-tuned has a relatively consistent object allocation rate, it is acceptable to raise the target survivor occupancy to something as high as -XX:TargetSurvivorRatio=80 or -XX:TargetSurvivorRatio=90. The advantage of being able to do so helps reduce the amount of survivor space needed to age objects. The challenge with setting -XX:TargetSurvivorRatio=<percent> higher is the HotSpot VM not being able to better adapt object aging in the presence of spikes in object allocation rates, which can lead to tenuring objects sooner than you would like. Tenuring objects too soon can contribute to increasing old generation space occupancy, which may lead to a higher probability of fragmentation since some of those promoted objects may not be long-lived objects and must be garbage collected in a future concurrent garbage collection cycle. Fragmentation is a situation to avoid since it contributes to the eventual likelihood of a full garbage collection.
-XX:+UseSerialGC
Enables the single threaded, stop-the-world, young generation, and old generation garbage collector. It is the oldest and most mature of the HotSpot VM garbage ollectors.
Generally, -XX:+UseSerialGC should be used only for small Java heap sizes such as -Xmx256m or smaller. The throughput garbage collector or concurrent garbage collector should be used in favor of -XX:+UseSerialGC with larger heap sizes.
-XX:+UseParallelGC
Enables the HotSpot VM’s multithreaded, stop-the-world throughput garbage collector. Only the young generation space utilizes a multithreaded garbage collector. The old generation space uses a single-threaded stop-the-world garbage collector. If -XX:+UseParallelOldGC is supported by the version of the HotSpot VM in use, -XX:+UseParallelOldGC should be used in favor of -XX:+UseParallelGC.
Also see -XX:ParallelGCThreads.
-XX:+UseParallelOldGC
Enables the HotSpot VM’s multithreaded, stop-the-world throughput garbage collector. Unlike -XX:+UseParallelGC, both a multithreaded young generation garbage collector and a multithreaded old generation garbage collector are used. -XX:+UseParallelOldGC auto-enables -XX:+UseParallelGC. If -XX:+UseParallelOldGC is not available in the HotSpot VM version in use, either migrate to a more recent version of the HotSpot VM or use -XX:+UseParallelGC.
Also see -XX:ParallelGCThreads.
-XX:-UseAdaptiveSizePolicy
Disables, (note the ‘–’ after the –XX: and before UseAdaptiveSizePolicy), a feature called adaptive sizing of the young generation’s eden and survivor spaces. Only the throughput garbage collector supports adaptive sizing. Enabling or disabling adaptive sizing with either the concurrent garbage collector or the serial garbage collector has no effect.
Specifying the throughout garbage collector via -XX:+UseParallelGC and -XX:+UseParallelOldGC auto-enables adaptive sizing. Adaptive sizing should be disabled only in situations where there is a desire to achieve higher performance throughput than can be offered with adaptive sizing enabled.
Also see -XX:+PrintAdaptiveSizePolicy.
-XX:+UseConcMarkSweepGC
Enables the HotSpot VM’s mostly concurrent garbage collector. It also auto-enables -XX:+UseParNewGC a multithreaded young generation garbage collector to use with the old generation concurrent garbage collector called CMS. The concurrent garbage collector should be used when application latency requirements cannot be met by the throughput garbage collector. Fine-tuning of young generation size, survivor space size, and the initiating of the CMS garbage collection cycle are usually required when using the concurrent garbage collector.
-XX:+UseParNewGC
Enables a multithreaded, stop-the-world, young generation garbage collector that should be used with the mostly concurrent old generation garbage collector CMS. -XX:+UseParNewGC is auto-enabled when -XX:+UseConcMarkSweepGC is specified.
Also see -XX:ParallelGCThreads.
-XX:ParallelGCThreads=<n>
Controls the number for parallel garbage collection threads to run when the multithreaded garbage collectors <n> is the number of threads to run. <n> defaults to the number returned by the Java API Runtime.available Processors() if the number returned is less than or equal to 8; otherwise, it defaults to 5/8 the number returned by Runtime.availableProcessors(). In cases where multiple applications are running on the same system, it is advisable to explicitly set the number of parallel garbage collection threads with -XX:ParallelGCThreads to a number lower than the default chosen by the Hot- Spot VM. The total number of garbage collection threads running on a system should not exceed the value returned by Runtime.availableProcessors().
-XX:MaxTenuringThreshold=<n>
Sets the maximum tenuring threshold to <n>. Used by the HotSpot VM as the maximum object age threshold at which it should promote objects from the young generation space to the old generation space. The -XX:MaxTenuringThreshold should be used when using the concurrent collector and fine-tuning the survivor spaces for effective object aging. Also see -XX:+PrintTenuringDistribution.
-XX:CMSInitiatingOccupancyFraction=<percent>
The percent of old generation space occupancy at which the first CMS garbage collection cycle should start. Subsequent starts of the CMS cycle are determined at a HotSpot ergonomically computed occupancy. If -XX:+UseCMSInitiatingOccupancyOnly is also specified, it is the percent of old generation space occupancy at which all CMS garbage collection cycles should start.
Generally, it is advisable to use both -XX:CMSInitiatingOccupancyFraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly.
-XX:+UseCMSInitiatingOccupancyOnly
Indicates all concurrent garbage collection CMS cycles should start based on the value of the -XX:CMSInitiatingOccupancyFraction. Generally, it is advisable to use both -XX:CMSInitiatingOccupancyFraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly.
Also see -XX:CMSInitiatingPermOccupancyFraction and -XX:CMSInitiatingOccupancyFraction=<percent>.
-XX:CMSInitiatingPermOccupancyFraction=<percent>
The percent of permanent generation space occupancy at which the first CMS garbage collection cycle should start. Subsequent starts of the CMS cycle are determined at a HotSpot ergonomically computed occupancy. If -XX:+UseCMSInitiatingOccupancyOnly is also specified, it is the percent of permanent generation space occupancy at which all CMS garbage collection cycles should start.
Generally, it is advisable to use both -XX:CMSInitiatingPermOccupancy Fraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly. Also see -XX:+UseCMSInitiatingOccupancyOnly.
-XX:+CMSClassUnloadingEnabled
Enables concurrent garbage collection of permanent generation. Use -XX:+CMSClassUnloadingEnabled when it is desirable for garbage collection of permanent generation to use CMS.Use of the Java 6 Update 3 or earlier also requires the use of -XX:+CMSPermGenSweepingEnabled.
-XX:+CMSPermGenSweepingEnabled
Enables permanent generation CMS garbage collection sweeping. Only applicable for Java 6 Update 3 or earlier JDKs and when -XX:+CMSClassLoadingEnabled is used.
-XX:+CMSScavengeBeforeRemark
Instructs the HotSpot VM to perform a minor garbage collection prior to executing a CMS remark.A minor garbage collection just prior to a CMS remark can minimize the amount of work for the remark phase by reducing the number of objects that may be reachable from the old generation space into the young generation space.Useful when wanting to reduce the duration of time it takes to complete a CMS cycle, especially a CMS remark.
Also see -XX:+UseConcMarkSweepGC.
-XX:+ScavengeBeforeFullGC
Instructs the HotSpot VM to garbage collect the young generation space before executing a full garbage collection.This is the default behavior for the HotSpot VM. It is generally not advisable to disable this option via -XX:-ScavengeBeforeFullGC since garbage collecting the young generation space before a full garbage collection can reduce the number of objects that may be reachable from the old generation space into the young generation space.
-XX:+ParallelRefProcEnabled
Enables multithreaded reference processing. This option can shorten the amount of time it takes the HotSpot VM to process Reference objects and finalizers.
-XX:+ExplicitGCInvokesConcurrent
Requests the HotSpot VM to execute any explicit GCs, i.e., System.gc() calls, to invoke a CMS cycle rather than a stop-the-world GC. Useful when it is desirable to avoid an explicit stop-the-world full garbage collection. It is generally advisable to use -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses in favor of -XX:+ExplicitGCInvokesConcurrent.Also see -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses.
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
Same as -XX:+ExplicitGCInvokesConcurrent with the addition of unloading of classes from the permanent generation space.It is generally advisable to use the -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses command line option over -XX:+ExplicitGCInvokesConcurrent.
-XX:+DisableExplicitGC
Disables full garbage collections invoked as a result of an explicit call to System.gc(). Useful in applications that explicitly call System.gc() without a known or justified reason to explicitly request a full garbage collection.Also see -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses and -XX:+ExplicitGCInvokesConcurrent.
-XX:+CMSIncrementalMode
Enables the incremental CMS concurrent garbage collector in which the concurrent phases of CMS are done incrementally, periodically stopping the concurrent phase to yield back the processor to application threads. Generally not recommended for multicore systems or large Java heaps.
-XX:+CMSIncrementalPacing
Enables automatic control of the amount of work the incremental CMS collector is allowed to do before giving up the processor, based on application behavior. Use only with -XX:+CMSIncrementalMode.
-verbose:gc
Enables reporting of basic garbage collection information at each garbage collection. Recommend using -XX:+PrintGCDetails over -verbose:gc.
-XX:+PrintGC
Enables reporting of basic garbage collection information at each garbage collection. Reports the same information as -verbose:gc. Recommend using -XX:+PrintGCDetails over -XX:+PrintGC.
-Xloggc:<filename>
Enables reporting of garbage collection statistics to a file with the supplied name for <filename>.A recommended practice is to capture to a log file with a minimum of the output of -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps and -XX:+PrintGCDetails.
-XX:+PrintGCDetails
Enables detailed reporting of garbage collection statistics from young generation, old generation, and permanent generation space. Recommended to use -XX:+PrintGCDetails over -verbose:gc and use -Xloggc:<filename> to capture the data in a log file.
-XX:+PrintGCTimeStamps
Enables the printing of a time stamp at each garbage collection indicating the amount of elapsed time since the JVM launched. Recommended to use -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps with -XX:+PrintGCDetails to provide a context of time when a garbage collection occurred.
-XX:+PrintGCDateStamps
Enables the printing of a localized date and time stamp at each garbage collection indicating the current date and time. Use -XX:+PrintGCDateStamps over -XX:+PrintGCTimeStamps when it is desirable to see wall clock time over a time stamp representing the time since JVM launch. Recommended to use -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps with -XX:+PrintGCDetails to provide a context of time when a garbage collection occurred.
-XX:+PrintTenuringDistribution
Enables the reporting of object tenuring statistics including the desired occupancy of survivor spaces to avoid premature tenuring of objects from a survivor space into old generation space, the HotSpot VM’s calculated tenuring threshold, the current maximum tenuring threshold, and an object age histogram showing object ages currently held in the survivor space. Useful to obtain tenuring information and object age information when tuning the young generation’s survivor spaces to control object aging or when objects are tenured to the old generation with the concurrent or serial garbage collector. Advisable to use this option in applications emphasizing low latency and continuously fine-tuning object aging or when objects are promoted from survivor space to old generation space.
-XX:+PrintAdaptiveSizePolicy
Enables the reporting of detailed garbage collection statistics of the throughput garbage collector including information on the number of bytes that have survived a minor garbage collection, how many bytes have been promoted in a minor garbage collection, whether survivor space has overflowed, a time stamp of when the minor garbage collection started, the major cost, mutator cost, the throughput goal, the amount of live space bytes, amount of free space bytes, the previous promotion size, the previous eden size, the desired promotion size, the desired eden size, and the current survivor space sizes. When adaptive sizing is disabled via -XX:-UseAdaptiveSizePolicy, reports only the number of bytes that have survived a minor garbage collection, how many bytes have been promoted in a minor garbage collection, and whether survivor space has overflowed. Useful when disabling adaptive sizing, -XX:-UseAdaptiveSizePolicy. The statistics produced are useful when explicitly fine-tuning the sizes of young generation’s eden and survivor spaces for effective object aging and tenuring of objects from survivor spaces to old generation space. Also see -XX:-UseAdaptiveSizePolicy.
-XX:+PrintGCApplicationStoppedTime
Enables the printing of the amount of time application threads have been stopped as the result of an internal HotSpot VM operation including stop-the-world garbage collections, stop-the-world phases of the CMS garbage collector, and any other safepoint operations. Useful in applications emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationConcurrentTime and -XX:+PrintSafe pointStatistics.
-XX:+PrintGCApplicationConcurrentTime
Enables the printing of the amount of time application threads have been executing concurrently with internal HotSpot VM threads. In other words, the amount of time application threads have been executing between HotSpot VM operations that caused application threads to be stopped. Useful in an application emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationStoppedTime and -XX:+PrintSafepoint Statistics.
-XX:+PrintSafepointStatistics
Enables the printing of HotSpot VM safepoint operations that have occurred and when they occurred. The output is printed at VM exit time. The output contains a line of output for each safepoint that occurred. Each line contains the time since VM launch of the safepoint operation occurred, type of VM operation, current number of threads active in the VM, current number of threads, current number of threads initially running, current number of threads waiting to block, amount of time in milliseconds threads spent spinning, amount of time in milliseconds threads spent blocked, amount of time threads spent in milliseconds synchronizing, amount of time in milliseconds threads spent cleaning, amount of time in milliseconds spent in VM operations, and number of page traps. A summary is printed at the end of the output summarizing the number of different safepoint operations along with a maximum synchronization time in milliseconds and the safepoint operation that took the maximum amount of time. Useful for applications emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationStoppedTime and -XX:+PrintGCAppli cationConcurrentTime.
-XX:+BackgroundCompilation
Instructs the JIT compiler to run as a background task, running the method in interpreter mode until the background compilation is finished. This option is enabled by default in HotSpot VMs. When writing micro-benchmarks, it can be useful to disable background compilation, -XX:-BackgroundCompilation, in an attempt to produce more deterministic behavior of the JIT compiler and more deterministic results of the micro-benchmark. -XX:-BackgroundCompilation, disabling background compilation, is also accomplished with -Xbatch. Also see -Xbatch.
-Xbatch
Disables JIT compiler background compilation, equivalent to -XX:-Background Compilation. Normally the HotSpot VM compiles the method as a background task,running the method in interpreter mode until the background compilation is finished. -XX:-BackgroundCompilation and -Xbatch disable background compilation so that JIT compilation of methods proceeds as a foreground task until completed. When writing micro-benchmarks, it can be useful to disable background compilation in an attempt to get more deterministic behavior of the JIT compiler and more deterministic results of the micro-benchmark. -Xbatch, disabling background compilation, is also accomplished with -XX:-BackgroundCompilation. Also see -XX:+BackgroundCompilation.
-XX:+TieredCompilation
Enables a JIT compilation policy to make initial quick JIT compilation decisions analogous to optimizations made by the HotSpot VM’s -client runtime and then continue to make more sophisticated JIT compilation decisions similar to those made by the VM’s -server runtime for frequently called Java methods in the program. In short, it uses a combination of the best of both -client and -server runtimes, quick compilation along sophisticated optimizations for frequently called Java methods. At the time of this writing, it is not recommended to use this command line option as a replacement for the -server runtime since the -server runtime offers better peak performance. This recommendation may change in the future as the tiered compilation feature is enhanced. Client applications running Java 6 Update 25 or later may consider using this command line option with the -server runtime (-server -XX:+TieredCompilation) as an alternative to the -client runtime. It is recommended you measure application startup performance and application responsiveness to assess whether the -server runtime with -XX:+TieredCompilation is better suited for the application than the -client runtime.
-XX:+PrintCompilation
Enables the printing of JIT compilation information for each method optimized by the HotSpot VM’s JIT compiler.Useful when wanting to know more about JIT compilation activities and in the creation or evaluation of micro-benchmarks.
Description of the output produced is as follows:
<id> <type> <method name> [bci] <(# of bytes)>
where id is
compile id, (uses at least three columns)
— if compiled method is a native method
type is none or more of
% – compile for on stack replacement (osr)
* | n – compiled method is native
s – compiled method is synchronized
! – compiled method has exception handler
b – interpreter blocked until compile completes
1 – compile without full optimization, tier 1 compilation
made not entrant – method deoptimized
made zombie – compiled method no longer valid
method name is
method name without signature
bci is
@ ## – for osr compiles, bytecode index of osr
# of bytes is
(## bytes) – # of bytes of bytecodes in method
Additional information on “made not entrant” and “made zombie”: “made not entrant” and “made zombie” are life cycle states of a JIT compiled method. Live JIT compiled methods are “made not entrant” as a result of executing an uncommon trap in the generated (machine) code. Uncommon traps are used to handle situations such as references to unloaded classes and to recover from some optimistic optimization that made assumptions that later turned out to be invalid. More formally, JIT compiled methods reported as “made not entrant” may still have live activations but are not allowed to run new activations. JIT compiled methods that are reported as “made zombie” are a later life cycle state. It means that there are no live activations of that compiled method. JIT compiled methods can go directly to the zombie state when a class is unloaded since it is known that all methods referencing that class are no longer live. JIT compiled methods reported as “made not entrant” transition to a reported “made zombie” state after the JIT compiler has detected that there no longer exists any live activations for that JIT compiled method. Once the JIT compiler is sure no other compiled method has references to a “made zombie” method, the “made zombie” method is freed. That is, it can be freed from the VM’s code cache where generated code is stored.
It is possible the output from -XX:+PrintCompilation may suggest that a method that is known to be executed frequently by an application has been deoptimized, but the output does not reflect that the method has been reoptimized. This can occur as a side-effect of method inlining done by the JIT compiler. If a frequently executed method is reported as deoptimized and it had been inlined, it is possible the -XX:+PrintCompilation output may not report the method as having been reoptimized.
-XX:+PrintInlining
Reports methods that are inlined or attempted to be inlined along with method byte size in bytecode. Use of -XX:+PrintInlining requires what is known as a HotSpot debug VM. Information from -XX:+PrintInlining can be used to fine-tune -XX:MaxInlineSize=<n>.
-XX:MaxInlineSize=<n>
Sets the maximum bytecode size beyond which a method is not inlined unless there is strong evidence that it should be inlined, such as profile information that suggests the method is a hot method. It is not advisable to use this command line option. Rarely do applications benefit from explicitly setting -XX:MaxInlineSize. Also see -XX:+PrintInlining.
-XX:+PrintOptoAssembly
Reports optimization decisions made by the HotSpot Server JIT compiler including generated assembly. Requires a HotSpot debug Server VM (works only with -server switch on Hot-Spot debug VMs).Useful for understanding and evaluating optimization decisions made by the Server JIT compiler, especially in micro-benchmarks. Generally, using a profiling tool such as Oracle Solaris Studio Performance Analyzer on Oracle Solaris or Linux offers a better way to observe compiler generated code for applications larger than a micro-benchmark. But, it does not offer any information on optimization decisions the compiler made in arriving at the generated assembly code shown in the Performance Analyzer.
-XX:+HeapDumpOnOutOfMemoryError
Enables the generation of a heap dump of the JVM’s heap spaces when an Out-OfMemoryError occurs.The heap dump created in the directory where the JVM is launched having a filename of the form java_pid<JVM process id>.hprof, where <JVM process id> is the process id of the JVM process executing the Java application.Useful when wanting to be able to perform memory usage analysis in the event an OutOfMemoryError occurs in a Java application.Also see -XX:HeapDumpPath=<path>.
-XX:HeapDumpPath=<path>
Sets the directory path to where a heap dump file is created to the path specified as <path>.
Useful when wanting to direct the generation of a heap dump file to a specific directory location.
-XX:OnOutOfMemoryError=<command or set of commands>
Enables the ability for a command or set of commands to be run when the HotSpot VM experiences an OutOfMemoryError. Useful when specific commands or operations are desirable if an OutOfMemory-Error occurs.
-XX:+ShowMessageBoxOnError
Enables an ability to have the HotSpot VM, before it exits, to display a dialog (GUI) box saying it has experienced a fatal error.This command line option essentially prevents the VM from exiting and provides the opportunity to attach a debugger to the VM to investigate the cause of the fatal error. Useful when wanting to diagnose a VM before it exits as a result of a fatal error.
-XX:OnError=<command or set of commands>
Enables the ability to invoke a set of commands when the application experiences an unexpected HotSpot VM exit.Useful when it is desirable to collect specific system information or invoke a debugger such as Oracle Solaris or Linux dbx or Window’s Winddbg to immediately examine the unexpected VM exit.
-Xcheck:jni
Enables an alternative set of debugging interfaces to be used by a Java application using the Java Native Interface to help with debugging issues associated with or introduced by the use of native code in a Java application. The alternative Java Native Interface introduced with this command line option verifies arguments to Java Native Interface calls more stringently, as well as performing additional internal consistency checks.Useful when wanting to confirm a JVM execution issue is not the result of an issue in how Java Native Interface methods are invoked.
-XX:+AggressiveOpts
Enables the latest HotSpot VM performance optimizations.Useful for a Java application in need of all the performance it can find. Performance optimizations when first introduced in the HotSpot VM usually come in under this command line option. After one or more releases, those optimizations are made the default.For application’s where stability or availability of the application is more important than performance, it is not suggested to use this command line option.
-XX:+AggressiveHeap
An encompassing command line option that enables a larger set of aggressive options including, but not limited to Java heap size and configuration or performance features. It is recommended to use -XX:+AggressiveOpts in favor of using -XX:+AggressiveHeap.
-XX:+UseBiasedLocking
Enables biased locking feature. Introduced in Java 5 HotSpot VMs; when enabled, it biases locking to the thread that previously held the lock. In uncontended lock situations, near lock free overhead can be realized.In Java 5 HotSpot VMs -XX:+UseBiasedLocking must be explicitly enabled to use the feature. In Java 6 HotSpot VMs this feature is automatically enabled by default. It must be explicitly disabled, -XX:-UseBiasedLocking, if this feature is not desired with Java 6 HotSpot VMs.Generally useful for most Java applications. Applications that predominately utilize locks in a manner where the thread that acquires a lock is not the same as the thread that acquired it last. An example would be an application where locking activity is dominated by locking activity around worker thread pools and worker threads. In this family of Java applications, since a HotSpot VM safepoint operation is required to revoke bias, it may be beneficial to explicitly disable biased locking, -XX:-UseBiasedLocking.
-XX:+DoEscapeAnalysis
Enables escape analysis optimization feature. An object, after it is allocated by some executing thread “escapes” if some other thread can ever see the allocated object. If an object does not escape, the HotSpot VM Server JIT compiler may perform any or all of the following optimizations:
– Object explosion; allocate an object’s fields in different places and potentially eliminate object allocations.
– Scalar replacement; store scalar fields in CPU registers.
– Thread stack allocation; store object fields in a stack frame.
– Eliminate synchronization.
– Eliminate garbage collection read/write barriers.
-XX:+DoEscapeAnalysis is automatically enabled with -XX:+AggressiveOpts,but otherwise disabled by default in Java 6 updates prior to Java 6 Update 23. Introduced in Java 6 Update 14.Also see -XX:+AggressiveOpts.
-XX:+UseLargePages
Enables use of large memory pages in the HotSpot VM.Automatically enabled on Oracle Solaris platforms. Not automatically enabled on Linux or Windows platforms.Use of -XX:+UseLargePages can reduce TLB (translation lookaside buffer) misses. 32-bit Intel and AMD x86 support 4 megabyte pages.
64-bit Intel and AMD x64 support 2 megabyte pages.Recent 64-bit Intel and AMD x64 supports up to 1 gigabyte pages.
SPARC T-series supports up to 256 megabyte pages with recent T-series supporting up to 2 gigabyte pages.
Oracle Solaris pagesize -a command reports page sizes supported by the underlying hardware. Large page support on Oracle Solaris requires no additional operating system configuration changes.
Linux getconf PAGESIZE or getconf PAGE_SIZE reports the currently configured page size. Linux requires additional operating system setup and configuration. The modifications required can vary depending on the Linux distribution and Linux kernel. It is advisable to consult a Linux administrator or your Linux distribution documentation for the appropriate changes. Windows requires additional operating system setup and configuration. Not all Windows operating systems provide large page support. Also see -XX:LargePageSizeInBytes and -XX:+AlwaysPreTouch.
-XX:LargePageSizeInBytes=<n>[g|m|k]
Enables use of large memory pages in the HotSpot VM with an explicit size. The underlying hardware platform must support the size <n>[g|m|k] page size. Otherwise, its use falls back to its default page size usage.
Useful when explicitly desiring a page size be used, i.e., 1 gigabyte pages on AMD or Intel platforms that support 1 gigabyte pages or 256 megabyte pages on SPARC T-series platforms or 2 gigabyte pages on recent SPARC T-series platforms. Also see -XX:+UseLargePages and -XX:+AlwaysPreTouch.
-XX:+AlwaysPreTouch
Enables the touching of all memory pages used by the JVM heap spaces during initialization of the HotSpot VM, which commits all memory pages at initialization time. By default, pages are committed only as they are needed. In other words, pages are committed as JVM heap space fills.
A garbage collection that copies to survivor space or promotes objects to the old generation space, which necessitates a new page may result in a longer garbage collection pause as a result of zeroing and committing the new page. Note, this additional overhead only occurs the first time there is a need for that additional page. If the HotSpot VM is using large pages in the absence of this command line option, the additional overhead of zeroing and committing the new page may be noticeable in garbage collection times. As a result it can be useful to use -XX:+AlwaysPreTouch when using large pages.
The enabling of -XX:+AlwaysPreTouch increases application startup time. But observing lengthier garbage collection pause times as a result of pages being zeroed and committed as JVM heap space is consumed is less likely.
-XX:+UseNUMA
Enables a JVM heap space allocation policy that helps overcome the time it takes to fetch data from memory by leveraging processor to memory node relationships by allocating objects in a memory node local to a processor on NUMA systems.
Introduced in Java 6 Update 2. As of this writing, it is available with the throughput collector only, -XX:+UseParallelOldGC and -XX:+UseParallelGC.On Oracle Solaris, with multiple JVM deployments that span more than one processor/memory node should also set lgrp_mem_pset_aware=1 in /etc/system.
Linux additionally requires use of the numacntl command. Use numacntl –interleave for single JVM deployments. For multiple JVM deployments where JVMs that span more than one processor/memory node, use numacntl –cpubind=<node number> –memnode=<node number>.
Windows under AMD additionally requires enabling node-interleaving in the BIOS for single JVM deployments. All Windows multiple JVM deployments, where JVMs that span more than one processor/memory node should use processor affinity, use the SET AFFINITY [mask] command. Useful in JVM deployments that span processor/memory nodes on a NUMA system.
-XX:+UseNUMA should not be used in JVM deployments where the JVM does not span processor/memory nodes.
-XX:+PrintCommandLineFlags
Enables the printing of ergonomically selected HotSpot VM settings based on the set of command line options explicitly specified. Useful when wanting to know the ergonomic values set by the HotSpot VM such as JVM heap space sizes and garbage collector selected.
-XX:+PrintFlagsFinal
Enables the printing of all production HotSpot VM command line option names and their corresponding values as they are set by the HotSpot VM based on the command line options explicitly specified and HotSpot VM defaults for options not specified. Introduced in Java 6 Update 19.
Useful when wanting to know the configuration of HotSpot VM options in use by a Java application. In contrast to -XX:+PrintCommandLineFlags, -XX:+PrintFlagsFinal prints all HotSpot VM options and their corresponding values as set by the HotSpot VM, not just those that are ergonomically set.
-client
Specifies that the HotSpot VM should optimize for client applications. At the present time, this option results in the use of the client JVM as the runtime environment. This command line option should be used when application startup time and small memory footprint are the most important performance criteria for the application, much more important than high throughput.
-server
Specifies that the HotSpot VM should optimize for server applications. At the present time, this option results in the use of the server JVM as the runtime environment. This command line option should be used when high application throughput is more important than startup time and small memory footprint.
-d64
Loads the 64-bit HotSpot VM instead of the default HotSpot 32-bit VM. This command line option should be used when there is a need to use a larger Java heap size than is possible with a 32-bit HotSpot VM. -XX:+UseCompressedOops should also be used in conjunction with this command line option for -Xmx and -Xms values less than 32 gigabytes. HotSpot versions later than Java 6 Update 18 enable -XX:+UseCompressedOops by default.
-XX:+UseCompressedOops
Enables a feature called compressed oops. Oops stands for ordinary object pointer, which is the means by which the HotSpot VM represents a reference to a Java object internally. 64-bit JVMs come with a performance penalty due to an increase in the size of Java references from 32 bits to 64 bits. This increase in width results in fewer ordinary object pointers being available on a CPU cache line, and as a result decreases CPU cache efficiency. The decrease in CPU cache efficiency on 64-bit JVMs often results in about an 8% to 20% performance degradation compared to a 32-bit JVM.
-XX:+UseCompressedOops can yield 32-bit JVM performance with the benefit of larger 64-bit JVM heaps. Some Java applications realize better performance with a 64-bit HotSpot VM using compressed oops than with a 32-bit HotSpot VM. The performance improvement realized from compressed oops arises from being able to transform a 64-bit pointer into a 32-bit offset from a Java heap base address. Useful when you want a Java heap larger than what can be specified for a 32-bit HotSpot VM but are not willing to sacrifice 32-bit VM performance. It should be used when specifying a Java heap up to 32 gigabytes (-Xmx32g), though best performance is realized up to about 26 gigabytes (-Xmx26g).
-Xms<n>[g|m|k]
The initial and minimum size of the Java heap, which includes the total size of the young generation space and old generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The Java heap will never be smaller than the value specified for -Xms. When -Xms is smaller than -Xmx, the size of Java heap may grow or contract depending on the needs of the application. However, growing or contracting the Java heap requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -Xms and -Xmx to the same value.
-Xmx<n>[g|m|k]
The maximum size of the Java heap, which includes the total size of the young generation space and old generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The Java heap will never grow to more than the value specified for -Xmx.
When -Xmx is larger than -Xms, the size of Java heap may grow or contract depending on the needs of the application. However, growing or contracting the Java heap requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -Xms and -Xmx to the same value.
-XX:NewSize=<n>[g|m|k]
The initial and minimum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space will never be smaller than the value specified. When -XX:NewSize is smaller than -XX:MaxNewSize, the size of the young generation space may grow or contract depending on the needs of the application. However, growing or contracting the young generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:NewSize and -XX:MaxNewSize to the same value.
-XX:MaxNewSize=<n>[g|m|k]
The maximum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space will never be larger than the value specified. When -XX:MaxNewSize is larger than -XX:NewSize, the size of the young generation space may grow or contract depending on the needs of the application. However, growing or contracting the young generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:MaxNewSize and -XX:NewSize to the same value.
-Xmn<n>[g|m|k]
Sets the initial, minimum, and maximum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space size will be set to the value specified.A convenient shortcut command line option to use when it is desirable to set -XX:NewSize and -XX:MaxNewSize to the same value.
-XX:NewRatio=<n>
The ratio between the young generation space size and old generation space size. For example, if n is 3, then the ratio is 1:3, and the young generation space size is onefourth of the total size of young generation space and old generation space. The ratio of the sizes of both young generation space and old generation space are maintained if the Java heap grows or contracts.A convenient command line option when -Xms and -Xmx are different sizes and there is a desire to maintain the same ratio of space between young generation space and old generation space.
-XX:PermSize=<n>[g|m|k]
The initial and minimum size of the permanent generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The permanent generation space will never be smaller than the value specified. When -XX:PermSize is smaller than -XX:MaxPermSize, the size of the permanent generation space may grow or contract depending on the needs of the application, in particular the need to load classes or store interned Strings. However, growing or contracting the permanent generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:PermSize and -XX:MaxPermSize to the same value.
-XX:MaxPermSize=<n>[g|m|k]
The maximum size of the permanent generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The permanent generation space will never be larger than the value specified. When -XX:MaxPermSize is larger than -XX:PermSize, the size of the permanent generation space may grow or contract depending on the needs of the application, in particular the need to load classes or store interned Strings. However, growing or contracting the permanent generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:PermSize and -XX:MaxPermSize to the same value.
-XX:SurvivorRatio=<n>
The ratio of the size of each survivor space to the eden space size, where <n> is the ratio. The following equation can be used to determine the survivor space size for a ratio specified with -XX:SurvivorRatio=<n>: survivor size = -Xmn<n>/(-XX:SurvivorRatio=<n> + 2)where -Xmn<n> is the size of the young generation space and -XX:SurvivorRatio=<n> is the value specified as the ratio. The reason for the + 2 in the equation is there are two survivor spaces. The larger the value specified as the ratio, the smaller the survivor space size. -XX:SurvivorRatio=<n> should be used when you want to explicitly size survivor spaces to manipulate object aging with the concurrent garbage collector, or to manipulate object aging with the throughput garbage collector when adaptive sizing is disabled using the command line option -XX:-UseAdaptiveSizePolicy.
-XX:SurvivorRatio=<n> should not be used with the throughput collector with adaptive sizing enabled. By default adaptive sizing is enabled with the throughput garbage collector by -XX:+UseParallelGC or -XX:+UseParallelOldGC. If an initial survivor ratio is desired for the throughput garbage collector’s adaptive sizing to begin with, then -XX:InitialSurvivorRatio=<n> should be used.
-XX:InitialSurvivorRatio=<n>
The initial survivor space ratio to use with the throughput garbage collector, where <n> is the ratio. It is only the initial survivor space ratio. This command line option is intended to be used with the throughput garbage collector with adaptive sizing enabled. Adaptive sizing resizes survivor spaces as the application behavior warrants. The following equation can be used to determine the initial survivor space size for a ratio specified with -XX:InitialSurvivorRatio=<n>: initial survivor size = -Xmn<n>/(-XX:InitialSurvivorRatio=<n> + 2)where -Xmn<n> is the size of the young generation space and -XX:Initial SurvivorRatio=<n> is the value specified as the ratio. The reason for the + 2 in the equation is there are two survivor spaces. The larger the value specified as the initial ratio, the smaller the initial survivor space size.
-XX:InitialSurvivorRatio=<n> should be used with the throughput collector with adaptive sizing enabled when there is a desire to specifically initially size survivor spaces. By default, adaptive sizing is enabled with the throughput garbage collector using -XX:+UseParallelGC or -XX:+UseParallelOldGC. If adaptive sizing is disabled, or the concurrent collector is in use, the -XX:SurvivorRatio=<n> command line option should be used when you want to explicitly size survivor spaces to manipulate object aging for the entire execution of the application.
-XX:TargetSurvivorRatio=<percent>
The survivor space occupancy the HotSpot VM should attempt to target after a minor garbage collection. The value to specify is a percentage of the size of a survivor space, rather than a ratio. Its default value is 50%.
Tuning the target survivor occupancy is rarely required. Through extensive testing of a vast variety of different types of application workloads by the HotSpot VM engineering team, a 50% target survivor space occupancy tends to work best for most applications since it helps deal with spikes in surviving objects seen at minor garbage collections in many disparate types of Java applications. If the application being fine-tuned has a relatively consistent object allocation rate, it is acceptable to raise the target survivor occupancy to something as high as -XX:TargetSurvivorRatio=80 or -XX:TargetSurvivorRatio=90. The advantage of being able to do so helps reduce the amount of survivor space needed to age objects. The challenge with setting -XX:TargetSurvivorRatio=<percent> higher is the HotSpot VM not being able to better adapt object aging in the presence of spikes in object allocation rates, which can lead to tenuring objects sooner than you would like. Tenuring objects too soon can contribute to increasing old generation space occupancy, which may lead to a higher probability of fragmentation since some of those promoted objects may not be long-lived objects and must be garbage collected in a future concurrent garbage collection cycle. Fragmentation is a situation to avoid since it contributes to the eventual likelihood of a full garbage collection.
-XX:+UseSerialGC
Enables the single threaded, stop-the-world, young generation, and old generation garbage collector. It is the oldest and most mature of the HotSpot VM garbage ollectors.
Generally, -XX:+UseSerialGC should be used only for small Java heap sizes such as -Xmx256m or smaller. The throughput garbage collector or concurrent garbage collector should be used in favor of -XX:+UseSerialGC with larger heap sizes.
-XX:+UseParallelGC
Enables the HotSpot VM’s multithreaded, stop-the-world throughput garbage collector. Only the young generation space utilizes a multithreaded garbage collector. The old generation space uses a single-threaded stop-the-world garbage collector. If -XX:+UseParallelOldGC is supported by the version of the HotSpot VM in use, -XX:+UseParallelOldGC should be used in favor of -XX:+UseParallelGC.
Also see -XX:ParallelGCThreads.
-XX:+UseParallelOldGC
Enables the HotSpot VM’s multithreaded, stop-the-world throughput garbage collector. Unlike -XX:+UseParallelGC, both a multithreaded young generation garbage collector and a multithreaded old generation garbage collector are used. -XX:+UseParallelOldGC auto-enables -XX:+UseParallelGC. If -XX:+UseParallelOldGC is not available in the HotSpot VM version in use, either migrate to a more recent version of the HotSpot VM or use -XX:+UseParallelGC.
Also see -XX:ParallelGCThreads.
-XX:-UseAdaptiveSizePolicy
Disables, (note the ‘–’ after the –XX: and before UseAdaptiveSizePolicy), a feature called adaptive sizing of the young generation’s eden and survivor spaces. Only the throughput garbage collector supports adaptive sizing. Enabling or disabling adaptive sizing with either the concurrent garbage collector or the serial garbage collector has no effect.
Specifying the throughout garbage collector via -XX:+UseParallelGC and -XX:+UseParallelOldGC auto-enables adaptive sizing. Adaptive sizing should be disabled only in situations where there is a desire to achieve higher performance throughput than can be offered with adaptive sizing enabled.
Also see -XX:+PrintAdaptiveSizePolicy.
-XX:+UseConcMarkSweepGC
Enables the HotSpot VM’s mostly concurrent garbage collector. It also auto-enables -XX:+UseParNewGC a multithreaded young generation garbage collector to use with the old generation concurrent garbage collector called CMS. The concurrent garbage collector should be used when application latency requirements cannot be met by the throughput garbage collector. Fine-tuning of young generation size, survivor space size, and the initiating of the CMS garbage collection cycle are usually required when using the concurrent garbage collector.
-XX:+UseParNewGC
Enables a multithreaded, stop-the-world, young generation garbage collector that should be used with the mostly concurrent old generation garbage collector CMS. -XX:+UseParNewGC is auto-enabled when -XX:+UseConcMarkSweepGC is specified.
Also see -XX:ParallelGCThreads.
-XX:ParallelGCThreads=<n>
Controls the number for parallel garbage collection threads to run when the multithreaded garbage collectors <n> is the number of threads to run. <n> defaults to the number returned by the Java API Runtime.available Processors() if the number returned is less than or equal to 8; otherwise, it defaults to 5/8 the number returned by Runtime.availableProcessors(). In cases where multiple applications are running on the same system, it is advisable to explicitly set the number of parallel garbage collection threads with -XX:ParallelGCThreads to a number lower than the default chosen by the Hot- Spot VM. The total number of garbage collection threads running on a system should not exceed the value returned by Runtime.availableProcessors().
-XX:MaxTenuringThreshold=<n>
Sets the maximum tenuring threshold to <n>. Used by the HotSpot VM as the maximum object age threshold at which it should promote objects from the young generation space to the old generation space. The -XX:MaxTenuringThreshold should be used when using the concurrent collector and fine-tuning the survivor spaces for effective object aging. Also see -XX:+PrintTenuringDistribution.
-XX:CMSInitiatingOccupancyFraction=<percent>
The percent of old generation space occupancy at which the first CMS garbage collection cycle should start. Subsequent starts of the CMS cycle are determined at a HotSpot ergonomically computed occupancy. If -XX:+UseCMSInitiatingOccupancyOnly is also specified, it is the percent of old generation space occupancy at which all CMS garbage collection cycles should start.
Generally, it is advisable to use both -XX:CMSInitiatingOccupancyFraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly.
-XX:+UseCMSInitiatingOccupancyOnly
Indicates all concurrent garbage collection CMS cycles should start based on the value of the -XX:CMSInitiatingOccupancyFraction. Generally, it is advisable to use both -XX:CMSInitiatingOccupancyFraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly.
Also see -XX:CMSInitiatingPermOccupancyFraction and -XX:CMSInitiatingOccupancyFraction=<percent>.
-XX:CMSInitiatingPermOccupancyFraction=<percent>
The percent of permanent generation space occupancy at which the first CMS garbage collection cycle should start. Subsequent starts of the CMS cycle are determined at a HotSpot ergonomically computed occupancy. If -XX:+UseCMSInitiatingOccupancyOnly is also specified, it is the percent of permanent generation space occupancy at which all CMS garbage collection cycles should start.
Generally, it is advisable to use both -XX:CMSInitiatingPermOccupancy Fraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly. Also see -XX:+UseCMSInitiatingOccupancyOnly.
-XX:+CMSClassUnloadingEnabled
Enables concurrent garbage collection of permanent generation. Use -XX:+CMSClassUnloadingEnabled when it is desirable for garbage collection of permanent generation to use CMS.Use of the Java 6 Update 3 or earlier also requires the use of -XX:+CMSPermGenSweepingEnabled.
-XX:+CMSPermGenSweepingEnabled
Enables permanent generation CMS garbage collection sweeping. Only applicable for Java 6 Update 3 or earlier JDKs and when -XX:+CMSClassLoadingEnabled is used.
-XX:+CMSScavengeBeforeRemark
Instructs the HotSpot VM to perform a minor garbage collection prior to executing a CMS remark.A minor garbage collection just prior to a CMS remark can minimize the amount of work for the remark phase by reducing the number of objects that may be reachable from the old generation space into the young generation space.Useful when wanting to reduce the duration of time it takes to complete a CMS cycle, especially a CMS remark.
Also see -XX:+UseConcMarkSweepGC.
-XX:+ScavengeBeforeFullGC
Instructs the HotSpot VM to garbage collect the young generation space before executing a full garbage collection.This is the default behavior for the HotSpot VM. It is generally not advisable to disable this option via -XX:-ScavengeBeforeFullGC since garbage collecting the young generation space before a full garbage collection can reduce the number of objects that may be reachable from the old generation space into the young generation space.
-XX:+ParallelRefProcEnabled
Enables multithreaded reference processing. This option can shorten the amount of time it takes the HotSpot VM to process Reference objects and finalizers.
-XX:+ExplicitGCInvokesConcurrent
Requests the HotSpot VM to execute any explicit GCs, i.e., System.gc() calls, to invoke a CMS cycle rather than a stop-the-world GC. Useful when it is desirable to avoid an explicit stop-the-world full garbage collection. It is generally advisable to use -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses in favor of -XX:+ExplicitGCInvokesConcurrent.Also see -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses.
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
Same as -XX:+ExplicitGCInvokesConcurrent with the addition of unloading of classes from the permanent generation space.It is generally advisable to use the -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses command line option over -XX:+ExplicitGCInvokesConcurrent.
-XX:+DisableExplicitGC
Disables full garbage collections invoked as a result of an explicit call to System.gc(). Useful in applications that explicitly call System.gc() without a known or justified reason to explicitly request a full garbage collection.Also see -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses and -XX:+ExplicitGCInvokesConcurrent.
-XX:+CMSIncrementalMode
Enables the incremental CMS concurrent garbage collector in which the concurrent phases of CMS are done incrementally, periodically stopping the concurrent phase to yield back the processor to application threads. Generally not recommended for multicore systems or large Java heaps.
-XX:+CMSIncrementalPacing
Enables automatic control of the amount of work the incremental CMS collector is allowed to do before giving up the processor, based on application behavior. Use only with -XX:+CMSIncrementalMode.
-verbose:gc
Enables reporting of basic garbage collection information at each garbage collection. Recommend using -XX:+PrintGCDetails over -verbose:gc.
-XX:+PrintGC
Enables reporting of basic garbage collection information at each garbage collection. Reports the same information as -verbose:gc. Recommend using -XX:+PrintGCDetails over -XX:+PrintGC.
-Xloggc:<filename>
Enables reporting of garbage collection statistics to a file with the supplied name for <filename>.A recommended practice is to capture to a log file with a minimum of the output of -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps and -XX:+PrintGCDetails.
-XX:+PrintGCDetails
Enables detailed reporting of garbage collection statistics from young generation, old generation, and permanent generation space. Recommended to use -XX:+PrintGCDetails over -verbose:gc and use -Xloggc:<filename> to capture the data in a log file.
-XX:+PrintGCTimeStamps
Enables the printing of a time stamp at each garbage collection indicating the amount of elapsed time since the JVM launched. Recommended to use -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps with -XX:+PrintGCDetails to provide a context of time when a garbage collection occurred.
-XX:+PrintGCDateStamps
Enables the printing of a localized date and time stamp at each garbage collection indicating the current date and time. Use -XX:+PrintGCDateStamps over -XX:+PrintGCTimeStamps when it is desirable to see wall clock time over a time stamp representing the time since JVM launch. Recommended to use -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps with -XX:+PrintGCDetails to provide a context of time when a garbage collection occurred.
-XX:+PrintTenuringDistribution
Enables the reporting of object tenuring statistics including the desired occupancy of survivor spaces to avoid premature tenuring of objects from a survivor space into old generation space, the HotSpot VM’s calculated tenuring threshold, the current maximum tenuring threshold, and an object age histogram showing object ages currently held in the survivor space. Useful to obtain tenuring information and object age information when tuning the young generation’s survivor spaces to control object aging or when objects are tenured to the old generation with the concurrent or serial garbage collector. Advisable to use this option in applications emphasizing low latency and continuously fine-tuning object aging or when objects are promoted from survivor space to old generation space.
-XX:+PrintAdaptiveSizePolicy
Enables the reporting of detailed garbage collection statistics of the throughput garbage collector including information on the number of bytes that have survived a minor garbage collection, how many bytes have been promoted in a minor garbage collection, whether survivor space has overflowed, a time stamp of when the minor garbage collection started, the major cost, mutator cost, the throughput goal, the amount of live space bytes, amount of free space bytes, the previous promotion size, the previous eden size, the desired promotion size, the desired eden size, and the current survivor space sizes. When adaptive sizing is disabled via -XX:-UseAdaptiveSizePolicy, reports only the number of bytes that have survived a minor garbage collection, how many bytes have been promoted in a minor garbage collection, and whether survivor space has overflowed. Useful when disabling adaptive sizing, -XX:-UseAdaptiveSizePolicy. The statistics produced are useful when explicitly fine-tuning the sizes of young generation’s eden and survivor spaces for effective object aging and tenuring of objects from survivor spaces to old generation space. Also see -XX:-UseAdaptiveSizePolicy.
-XX:+PrintGCApplicationStoppedTime
Enables the printing of the amount of time application threads have been stopped as the result of an internal HotSpot VM operation including stop-the-world garbage collections, stop-the-world phases of the CMS garbage collector, and any other safepoint operations. Useful in applications emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationConcurrentTime and -XX:+PrintSafe pointStatistics.
-XX:+PrintGCApplicationConcurrentTime
Enables the printing of the amount of time application threads have been executing concurrently with internal HotSpot VM threads. In other words, the amount of time application threads have been executing between HotSpot VM operations that caused application threads to be stopped. Useful in an application emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationStoppedTime and -XX:+PrintSafepoint Statistics.
-XX:+PrintSafepointStatistics
Enables the printing of HotSpot VM safepoint operations that have occurred and when they occurred. The output is printed at VM exit time. The output contains a line of output for each safepoint that occurred. Each line contains the time since VM launch of the safepoint operation occurred, type of VM operation, current number of threads active in the VM, current number of threads, current number of threads initially running, current number of threads waiting to block, amount of time in milliseconds threads spent spinning, amount of time in milliseconds threads spent blocked, amount of time threads spent in milliseconds synchronizing, amount of time in milliseconds threads spent cleaning, amount of time in milliseconds spent in VM operations, and number of page traps. A summary is printed at the end of the output summarizing the number of different safepoint operations along with a maximum synchronization time in milliseconds and the safepoint operation that took the maximum amount of time. Useful for applications emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationStoppedTime and -XX:+PrintGCAppli cationConcurrentTime.
-XX:+BackgroundCompilation
Instructs the JIT compiler to run as a background task, running the method in interpreter mode until the background compilation is finished. This option is enabled by default in HotSpot VMs. When writing micro-benchmarks, it can be useful to disable background compilation, -XX:-BackgroundCompilation, in an attempt to produce more deterministic behavior of the JIT compiler and more deterministic results of the micro-benchmark. -XX:-BackgroundCompilation, disabling background compilation, is also accomplished with -Xbatch. Also see -Xbatch.
-Xbatch
Disables JIT compiler background compilation, equivalent to -XX:-Background Compilation. Normally the HotSpot VM compiles the method as a background task,running the method in interpreter mode until the background compilation is finished. -XX:-BackgroundCompilation and -Xbatch disable background compilation so that JIT compilation of methods proceeds as a foreground task until completed. When writing micro-benchmarks, it can be useful to disable background compilation in an attempt to get more deterministic behavior of the JIT compiler and more deterministic results of the micro-benchmark. -Xbatch, disabling background compilation, is also accomplished with -XX:-BackgroundCompilation. Also see -XX:+BackgroundCompilation.
-XX:+TieredCompilation
Enables a JIT compilation policy to make initial quick JIT compilation decisions analogous to optimizations made by the HotSpot VM’s -client runtime and then continue to make more sophisticated JIT compilation decisions similar to those made by the VM’s -server runtime for frequently called Java methods in the program. In short, it uses a combination of the best of both -client and -server runtimes, quick compilation along sophisticated optimizations for frequently called Java methods. At the time of this writing, it is not recommended to use this command line option as a replacement for the -server runtime since the -server runtime offers better peak performance. This recommendation may change in the future as the tiered compilation feature is enhanced. Client applications running Java 6 Update 25 or later may consider using this command line option with the -server runtime (-server -XX:+TieredCompilation) as an alternative to the -client runtime. It is recommended you measure application startup performance and application responsiveness to assess whether the -server runtime with -XX:+TieredCompilation is better suited for the application than the -client runtime.
-XX:+PrintCompilation
Enables the printing of JIT compilation information for each method optimized by the HotSpot VM’s JIT compiler.Useful when wanting to know more about JIT compilation activities and in the creation or evaluation of micro-benchmarks.
Description of the output produced is as follows:
<id> <type> <method name> [bci] <(# of bytes)>
where id is
compile id, (uses at least three columns)
— if compiled method is a native method
type is none or more of
% – compile for on stack replacement (osr)
* | n – compiled method is native
s – compiled method is synchronized
! – compiled method has exception handler
b – interpreter blocked until compile completes
1 – compile without full optimization, tier 1 compilation
made not entrant – method deoptimized
made zombie – compiled method no longer valid
method name is
method name without signature
bci is
@ ## – for osr compiles, bytecode index of osr
# of bytes is
(## bytes) – # of bytes of bytecodes in method
Additional information on “made not entrant” and “made zombie”: “made not entrant” and “made zombie” are life cycle states of a JIT compiled method. Live JIT compiled methods are “made not entrant” as a result of executing an uncommon trap in the generated (machine) code. Uncommon traps are used to handle situations such as references to unloaded classes and to recover from some optimistic optimization that made assumptions that later turned out to be invalid. More formally, JIT compiled methods reported as “made not entrant” may still have live activations but are not allowed to run new activations. JIT compiled methods that are reported as “made zombie” are a later life cycle state. It means that there are no live activations of that compiled method. JIT compiled methods can go directly to the zombie state when a class is unloaded since it is known that all methods referencing that class are no longer live. JIT compiled methods reported as “made not entrant” transition to a reported “made zombie” state after the JIT compiler has detected that there no longer exists any live activations for that JIT compiled method. Once the JIT compiler is sure no other compiled method has references to a “made zombie” method, the “made zombie” method is freed. That is, it can be freed from the VM’s code cache where generated code is stored.
It is possible the output from -XX:+PrintCompilation may suggest that a method that is known to be executed frequently by an application has been deoptimized, but the output does not reflect that the method has been reoptimized. This can occur as a side-effect of method inlining done by the JIT compiler. If a frequently executed method is reported as deoptimized and it had been inlined, it is possible the -XX:+PrintCompilation output may not report the method as having been reoptimized.
-XX:+PrintInlining
Reports methods that are inlined or attempted to be inlined along with method byte size in bytecode. Use of -XX:+PrintInlining requires what is known as a HotSpot debug VM. Information from -XX:+PrintInlining can be used to fine-tune -XX:MaxInlineSize=<n>.
-XX:MaxInlineSize=<n>
Sets the maximum bytecode size beyond which a method is not inlined unless there is strong evidence that it should be inlined, such as profile information that suggests the method is a hot method. It is not advisable to use this command line option. Rarely do applications benefit from explicitly setting -XX:MaxInlineSize. Also see -XX:+PrintInlining.
-XX:+PrintOptoAssembly
Reports optimization decisions made by the HotSpot Server JIT compiler including generated assembly. Requires a HotSpot debug Server VM (works only with -server switch on Hot-Spot debug VMs).Useful for understanding and evaluating optimization decisions made by the Server JIT compiler, especially in micro-benchmarks. Generally, using a profiling tool such as Oracle Solaris Studio Performance Analyzer on Oracle Solaris or Linux offers a better way to observe compiler generated code for applications larger than a micro-benchmark. But, it does not offer any information on optimization decisions the compiler made in arriving at the generated assembly code shown in the Performance Analyzer.
-XX:+HeapDumpOnOutOfMemoryError
Enables the generation of a heap dump of the JVM’s heap spaces when an Out-OfMemoryError occurs.The heap dump created in the directory where the JVM is launched having a filename of the form java_pid<JVM process id>.hprof, where <JVM process id> is the process id of the JVM process executing the Java application.Useful when wanting to be able to perform memory usage analysis in the event an OutOfMemoryError occurs in a Java application.Also see -XX:HeapDumpPath=<path>.
-XX:HeapDumpPath=<path>
Sets the directory path to where a heap dump file is created to the path specified as <path>.
Useful when wanting to direct the generation of a heap dump file to a specific directory location.
-XX:OnOutOfMemoryError=<command or set of commands>
Enables the ability for a command or set of commands to be run when the HotSpot VM experiences an OutOfMemoryError. Useful when specific commands or operations are desirable if an OutOfMemory-Error occurs.
-XX:+ShowMessageBoxOnError
Enables an ability to have the HotSpot VM, before it exits, to display a dialog (GUI) box saying it has experienced a fatal error.This command line option essentially prevents the VM from exiting and provides the opportunity to attach a debugger to the VM to investigate the cause of the fatal error. Useful when wanting to diagnose a VM before it exits as a result of a fatal error.
-XX:OnError=<command or set of commands>
Enables the ability to invoke a set of commands when the application experiences an unexpected HotSpot VM exit.Useful when it is desirable to collect specific system information or invoke a debugger such as Oracle Solaris or Linux dbx or Window’s Winddbg to immediately examine the unexpected VM exit.
-Xcheck:jni
Enables an alternative set of debugging interfaces to be used by a Java application using the Java Native Interface to help with debugging issues associated with or introduced by the use of native code in a Java application. The alternative Java Native Interface introduced with this command line option verifies arguments to Java Native Interface calls more stringently, as well as performing additional internal consistency checks.Useful when wanting to confirm a JVM execution issue is not the result of an issue in how Java Native Interface methods are invoked.
-XX:+AggressiveOpts
Enables the latest HotSpot VM performance optimizations.Useful for a Java application in need of all the performance it can find. Performance optimizations when first introduced in the HotSpot VM usually come in under this command line option. After one or more releases, those optimizations are made the default.For application’s where stability or availability of the application is more important than performance, it is not suggested to use this command line option.
-XX:+AggressiveHeap
An encompassing command line option that enables a larger set of aggressive options including, but not limited to Java heap size and configuration or performance features. It is recommended to use -XX:+AggressiveOpts in favor of using -XX:+AggressiveHeap.
-XX:+UseBiasedLocking
Enables biased locking feature. Introduced in Java 5 HotSpot VMs; when enabled, it biases locking to the thread that previously held the lock. In uncontended lock situations, near lock free overhead can be realized.In Java 5 HotSpot VMs -XX:+UseBiasedLocking must be explicitly enabled to use the feature. In Java 6 HotSpot VMs this feature is automatically enabled by default. It must be explicitly disabled, -XX:-UseBiasedLocking, if this feature is not desired with Java 6 HotSpot VMs.Generally useful for most Java applications. Applications that predominately utilize locks in a manner where the thread that acquires a lock is not the same as the thread that acquired it last. An example would be an application where locking activity is dominated by locking activity around worker thread pools and worker threads. In this family of Java applications, since a HotSpot VM safepoint operation is required to revoke bias, it may be beneficial to explicitly disable biased locking, -XX:-UseBiasedLocking.
-XX:+DoEscapeAnalysis
Enables escape analysis optimization feature. An object, after it is allocated by some executing thread “escapes” if some other thread can ever see the allocated object. If an object does not escape, the HotSpot VM Server JIT compiler may perform any or all of the following optimizations:
– Object explosion; allocate an object’s fields in different places and potentially eliminate object allocations.
– Scalar replacement; store scalar fields in CPU registers.
– Thread stack allocation; store object fields in a stack frame.
– Eliminate synchronization.
– Eliminate garbage collection read/write barriers.
-XX:+DoEscapeAnalysis is automatically enabled with -XX:+AggressiveOpts,but otherwise disabled by default in Java 6 updates prior to Java 6 Update 23. Introduced in Java 6 Update 14.Also see -XX:+AggressiveOpts.
-XX:+UseLargePages
Enables use of large memory pages in the HotSpot VM.Automatically enabled on Oracle Solaris platforms. Not automatically enabled on Linux or Windows platforms.Use of -XX:+UseLargePages can reduce TLB (translation lookaside buffer) misses. 32-bit Intel and AMD x86 support 4 megabyte pages.
64-bit Intel and AMD x64 support 2 megabyte pages.Recent 64-bit Intel and AMD x64 supports up to 1 gigabyte pages.
SPARC T-series supports up to 256 megabyte pages with recent T-series supporting up to 2 gigabyte pages.
Oracle Solaris pagesize -a command reports page sizes supported by the underlying hardware. Large page support on Oracle Solaris requires no additional operating system configuration changes.
Linux getconf PAGESIZE or getconf PAGE_SIZE reports the currently configured page size. Linux requires additional operating system setup and configuration. The modifications required can vary depending on the Linux distribution and Linux kernel. It is advisable to consult a Linux administrator or your Linux distribution documentation for the appropriate changes. Windows requires additional operating system setup and configuration. Not all Windows operating systems provide large page support. Also see -XX:LargePageSizeInBytes and -XX:+AlwaysPreTouch.
-XX:LargePageSizeInBytes=<n>[g|m|k]
Enables use of large memory pages in the HotSpot VM with an explicit size. The underlying hardware platform must support the size <n>[g|m|k] page size. Otherwise, its use falls back to its default page size usage.
Useful when explicitly desiring a page size be used, i.e., 1 gigabyte pages on AMD or Intel platforms that support 1 gigabyte pages or 256 megabyte pages on SPARC T-series platforms or 2 gigabyte pages on recent SPARC T-series platforms. Also see -XX:+UseLargePages and -XX:+AlwaysPreTouch.
-XX:+AlwaysPreTouch
Enables the touching of all memory pages used by the JVM heap spaces during initialization of the HotSpot VM, which commits all memory pages at initialization time. By default, pages are committed only as they are needed. In other words, pages are committed as JVM heap space fills.
A garbage collection that copies to survivor space or promotes objects to the old generation space, which necessitates a new page may result in a longer garbage collection pause as a result of zeroing and committing the new page. Note, this additional overhead only occurs the first time there is a need for that additional page. If the HotSpot VM is using large pages in the absence of this command line option, the additional overhead of zeroing and committing the new page may be noticeable in garbage collection times. As a result it can be useful to use -XX:+AlwaysPreTouch when using large pages.
The enabling of -XX:+AlwaysPreTouch increases application startup time. But observing lengthier garbage collection pause times as a result of pages being zeroed and committed as JVM heap space is consumed is less likely.
-XX:+UseNUMA
Enables a JVM heap space allocation policy that helps overcome the time it takes to fetch data from memory by leveraging processor to memory node relationships by allocating objects in a memory node local to a processor on NUMA systems.
Introduced in Java 6 Update 2. As of this writing, it is available with the throughput collector only, -XX:+UseParallelOldGC and -XX:+UseParallelGC.On Oracle Solaris, with multiple JVM deployments that span more than one processor/memory node should also set lgrp_mem_pset_aware=1 in /etc/system.
Linux additionally requires use of the numacntl command. Use numacntl –interleave for single JVM deployments. For multiple JVM deployments where JVMs that span more than one processor/memory node, use numacntl –cpubind=<node number> –memnode=<node number>.
Windows under AMD additionally requires enabling node-interleaving in the BIOS for single JVM deployments. All Windows multiple JVM deployments, where JVMs that span more than one processor/memory node should use processor affinity, use the SET AFFINITY [mask] command. Useful in JVM deployments that span processor/memory nodes on a NUMA system.
-XX:+UseNUMA should not be used in JVM deployments where the JVM does not span processor/memory nodes.
-XX:+PrintCommandLineFlags
Enables the printing of ergonomically selected HotSpot VM settings based on the set of command line options explicitly specified. Useful when wanting to know the ergonomic values set by the HotSpot VM such as JVM heap space sizes and garbage collector selected.
-XX:+PrintFlagsFinal
Enables the printing of all production HotSpot VM command line option names and their corresponding values as they are set by the HotSpot VM based on the command line options explicitly specified and HotSpot VM defaults for options not specified. Introduced in Java 6 Update 19.
Useful when wanting to know the configuration of HotSpot VM options in use by a Java application. In contrast to -XX:+PrintCommandLineFlags, -XX:+PrintFlagsFinal prints all HotSpot VM options and their corresponding values as set by the HotSpot VM, not just those that are ergonomically set.
http://www.techpaste.com/2012/02/java-command-line-options-jvm-performance-improvement/
-client
Specifies that the HotSpot VM should optimize for client applications. At the present time, this option results in the use of the client JVM as the runtime environment. This command line option should be used when application startup time and small memory footprint are the most important performance criteria for the application, much more important than high throughput.
-server
Specifies that the HotSpot VM should optimize for server applications. At the present time, this option results in the use of the server JVM as the runtime environment. This command line option should be used when high application throughput is more important than startup time and small memory footprint.
-d64
Loads the 64-bit HotSpot VM instead of the default HotSpot 32-bit VM. This command line option should be used when there is a need to use a larger Java heap size than is possible with a 32-bit HotSpot VM. -XX:+UseCompressedOops should also be used in conjunction with this command line option for -Xmx and -Xms values less than 32 gigabytes. HotSpot versions later than Java 6 Update 18 enable -XX:+UseCompressedOops by default.
-XX:+UseCompressedOops
Enables a feature called compressed oops. Oops stands for ordinary object pointer, which is the means by which the HotSpot VM represents a reference to a Java object internally. 64-bit JVMs come with a performance penalty due to an increase in the size of Java references from 32 bits to 64 bits. This increase in width results in fewer ordinary object pointers being available on a CPU cache line, and as a result decreases CPU cache efficiency. The decrease in CPU cache efficiency on 64-bit JVMs often results in about an 8% to 20% performance degradation compared to a 32-bit JVM.
-XX:+UseCompressedOops can yield 32-bit JVM performance with the benefit of larger 64-bit JVM heaps. Some Java applications realize better performance with a 64-bit HotSpot VM using compressed oops than with a 32-bit HotSpot VM. The performance improvement realized from compressed oops arises from being able to transform a 64-bit pointer into a 32-bit offset from a Java heap base address. Useful when you want a Java heap larger than what can be specified for a 32-bit HotSpot VM but are not willing to sacrifice 32-bit VM performance. It should be used when specifying a Java heap up to 32 gigabytes (-Xmx32g), though best performance is realized up to about 26 gigabytes (-Xmx26g).
-Xms<n>[g|m|k]
The initial and minimum size of the Java heap, which includes the total size of the young generation space and old generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The Java heap will never be smaller than the value specified for -Xms. When -Xms is smaller than -Xmx, the size of Java heap may grow or contract depending on the needs of the application. However, growing or contracting the Java heap requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -Xms and -Xmx to the same value.
-Xmx<n>[g|m|k]
The maximum size of the Java heap, which includes the total size of the young generation space and old generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The Java heap will never grow to more than the value specified for -Xmx.
When -Xmx is larger than -Xms, the size of Java heap may grow or contract depending on the needs of the application. However, growing or contracting the Java heap requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -Xms and -Xmx to the same value.
-XX:NewSize=<n>[g|m|k]
The initial and minimum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space will never be smaller than the value specified. When -XX:NewSize is smaller than -XX:MaxNewSize, the size of the young generation space may grow or contract depending on the needs of the application. However, growing or contracting the young generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:NewSize and -XX:MaxNewSize to the same value.
-XX:MaxNewSize=<n>[g|m|k]
The maximum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space will never be larger than the value specified. When -XX:MaxNewSize is larger than -XX:NewSize, the size of the young generation space may grow or contract depending on the needs of the application. However, growing or contracting the young generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:MaxNewSize and -XX:NewSize to the same value.
-Xmn<n>[g|m|k]
Sets the initial, minimum, and maximum size of the young generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The young generation space size will be set to the value specified.A convenient shortcut command line option to use when it is desirable to set -XX:NewSize and -XX:MaxNewSize to the same value.
-XX:NewRatio=<n>
The ratio between the young generation space size and old generation space size. For example, if n is 3, then the ratio is 1:3, and the young generation space size is onefourth of the total size of young generation space and old generation space. The ratio of the sizes of both young generation space and old generation space are maintained if the Java heap grows or contracts.A convenient command line option when -Xms and -Xmx are different sizes and there is a desire to maintain the same ratio of space between young generation space and old generation space.
-XX:PermSize=<n>[g|m|k]
The initial and minimum size of the permanent generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The permanent generation space will never be smaller than the value specified. When -XX:PermSize is smaller than -XX:MaxPermSize, the size of the permanent generation space may grow or contract depending on the needs of the application, in particular the need to load classes or store interned Strings. However, growing or contracting the permanent generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:PermSize and -XX:MaxPermSize to the same value.
-XX:MaxPermSize=<n>[g|m|k]
The maximum size of the permanent generation space. <n> is the size. [g|m|k] indicates whether the size should be interpreted as gigabytes, megabytes, or kilobytes. The permanent generation space will never be larger than the value specified. When -XX:MaxPermSize is larger than -XX:PermSize, the size of the permanent generation space may grow or contract depending on the needs of the application, in particular the need to load classes or store interned Strings. However, growing or contracting the permanent generation space requires a full garbage collection. Applications with a focus on latency or throughput performance tend to set -XX:PermSize and -XX:MaxPermSize to the same value.
-XX:SurvivorRatio=<n>
The ratio of the size of each survivor space to the eden space size, where <n> is the ratio. The following equation can be used to determine the survivor space size for a ratio specified with -XX:SurvivorRatio=<n>: survivor size = -Xmn<n>/(-XX:SurvivorRatio=<n> + 2)where -Xmn<n> is the size of the young generation space and -XX:SurvivorRatio=<n> is the value specified as the ratio. The reason for the + 2 in the equation is there are two survivor spaces. The larger the value specified as the ratio, the smaller the survivor space size. -XX:SurvivorRatio=<n> should be used when you want to explicitly size survivor spaces to manipulate object aging with the concurrent garbage collector, or to manipulate object aging with the throughput garbage collector when adaptive sizing is disabled using the command line option -XX:-UseAdaptiveSizePolicy.
-XX:SurvivorRatio=<n> should not be used with the throughput collector with adaptive sizing enabled. By default adaptive sizing is enabled with the throughput garbage collector by -XX:+UseParallelGC or -XX:+UseParallelOldGC. If an initial survivor ratio is desired for the throughput garbage collector’s adaptive sizing to begin with, then -XX:InitialSurvivorRatio=<n> should be used.
-XX:InitialSurvivorRatio=<n>
The initial survivor space ratio to use with the throughput garbage collector, where <n> is the ratio. It is only the initial survivor space ratio. This command line option is intended to be used with the throughput garbage collector with adaptive sizing enabled. Adaptive sizing resizes survivor spaces as the application behavior warrants. The following equation can be used to determine the initial survivor space size for a ratio specified with -XX:InitialSurvivorRatio=<n>: initial survivor size = -Xmn<n>/(-XX:InitialSurvivorRatio=<n> + 2)where -Xmn<n> is the size of the young generation space and -XX:Initial SurvivorRatio=<n> is the value specified as the ratio. The reason for the + 2 in the equation is there are two survivor spaces. The larger the value specified as the initial ratio, the smaller the initial survivor space size.
-XX:InitialSurvivorRatio=<n> should be used with the throughput collector with adaptive sizing enabled when there is a desire to specifically initially size survivor spaces. By default, adaptive sizing is enabled with the throughput garbage collector using -XX:+UseParallelGC or -XX:+UseParallelOldGC. If adaptive sizing is disabled, or the concurrent collector is in use, the -XX:SurvivorRatio=<n> command line option should be used when you want to explicitly size survivor spaces to manipulate object aging for the entire execution of the application.
-XX:TargetSurvivorRatio=<percent>
The survivor space occupancy the HotSpot VM should attempt to target after a minor garbage collection. The value to specify is a percentage of the size of a survivor space, rather than a ratio. Its default value is 50%.
Tuning the target survivor occupancy is rarely required. Through extensive testing of a vast variety of different types of application workloads by the HotSpot VM engineering team, a 50% target survivor space occupancy tends to work best for most applications since it helps deal with spikes in surviving objects seen at minor garbage collections in many disparate types of Java applications. If the application being fine-tuned has a relatively consistent object allocation rate, it is acceptable to raise the target survivor occupancy to something as high as -XX:TargetSurvivorRatio=80 or -XX:TargetSurvivorRatio=90. The advantage of being able to do so helps reduce the amount of survivor space needed to age objects. The challenge with setting -XX:TargetSurvivorRatio=<percent> higher is the HotSpot VM not being able to better adapt object aging in the presence of spikes in object allocation rates, which can lead to tenuring objects sooner than you would like. Tenuring objects too soon can contribute to increasing old generation space occupancy, which may lead to a higher probability of fragmentation since some of those promoted objects may not be long-lived objects and must be garbage collected in a future concurrent garbage collection cycle. Fragmentation is a situation to avoid since it contributes to the eventual likelihood of a full garbage collection.
-XX:+UseSerialGC
Enables the single threaded, stop-the-world, young generation, and old generation garbage collector. It is the oldest and most mature of the HotSpot VM garbage ollectors.
Generally, -XX:+UseSerialGC should be used only for small Java heap sizes such as -Xmx256m or smaller. The throughput garbage collector or concurrent garbage collector should be used in favor of -XX:+UseSerialGC with larger heap sizes.
-XX:+UseParallelGC
Enables the HotSpot VM’s multithreaded, stop-the-world throughput garbage collector. Only the young generation space utilizes a multithreaded garbage collector. The old generation space uses a single-threaded stop-the-world garbage collector. If -XX:+UseParallelOldGC is supported by the version of the HotSpot VM in use, -XX:+UseParallelOldGC should be used in favor of -XX:+UseParallelGC.
Also see -XX:ParallelGCThreads.
-XX:+UseParallelOldGC
Enables the HotSpot VM’s multithreaded, stop-the-world throughput garbage collector. Unlike -XX:+UseParallelGC, both a multithreaded young generation garbage collector and a multithreaded old generation garbage collector are used. -XX:+UseParallelOldGC auto-enables -XX:+UseParallelGC. If -XX:+UseParallelOldGC is not available in the HotSpot VM version in use, either migrate to a more recent version of the HotSpot VM or use -XX:+UseParallelGC.
Also see -XX:ParallelGCThreads.
-XX:-UseAdaptiveSizePolicy
Disables, (note the ‘–’ after the –XX: and before UseAdaptiveSizePolicy), a feature called adaptive sizing of the young generation’s eden and survivor spaces. Only the throughput garbage collector supports adaptive sizing. Enabling or disabling adaptive sizing with either the concurrent garbage collector or the serial garbage collector has no effect.
Specifying the throughout garbage collector via -XX:+UseParallelGC and -XX:+UseParallelOldGC auto-enables adaptive sizing. Adaptive sizing should be disabled only in situations where there is a desire to achieve higher performance throughput than can be offered with adaptive sizing enabled.
Also see -XX:+PrintAdaptiveSizePolicy.
-XX:+UseConcMarkSweepGC
Enables the HotSpot VM’s mostly concurrent garbage collector. It also auto-enables -XX:+UseParNewGC a multithreaded young generation garbage collector to use with the old generation concurrent garbage collector called CMS. The concurrent garbage collector should be used when application latency requirements cannot be met by the throughput garbage collector. Fine-tuning of young generation size, survivor space size, and the initiating of the CMS garbage collection cycle are usually required when using the concurrent garbage collector.
-XX:+UseParNewGC
Enables a multithreaded, stop-the-world, young generation garbage collector that should be used with the mostly concurrent old generation garbage collector CMS. -XX:+UseParNewGC is auto-enabled when -XX:+UseConcMarkSweepGC is specified.
Also see -XX:ParallelGCThreads.
-XX:ParallelGCThreads=<n>
Controls the number for parallel garbage collection threads to run when the multithreaded garbage collectors <n> is the number of threads to run. <n> defaults to the number returned by the Java API Runtime.available Processors() if the number returned is less than or equal to 8; otherwise, it defaults to 5/8 the number returned by Runtime.availableProcessors(). In cases where multiple applications are running on the same system, it is advisable to explicitly set the number of parallel garbage collection threads with -XX:ParallelGCThreads to a number lower than the default chosen by the Hot- Spot VM. The total number of garbage collection threads running on a system should not exceed the value returned by Runtime.availableProcessors().
-XX:MaxTenuringThreshold=<n>
Sets the maximum tenuring threshold to <n>. Used by the HotSpot VM as the maximum object age threshold at which it should promote objects from the young generation space to the old generation space. The -XX:MaxTenuringThreshold should be used when using the concurrent collector and fine-tuning the survivor spaces for effective object aging. Also see -XX:+PrintTenuringDistribution.
-XX:CMSInitiatingOccupancyFraction=<percent>
The percent of old generation space occupancy at which the first CMS garbage collection cycle should start. Subsequent starts of the CMS cycle are determined at a HotSpot ergonomically computed occupancy. If -XX:+UseCMSInitiatingOccupancyOnly is also specified, it is the percent of old generation space occupancy at which all CMS garbage collection cycles should start.
Generally, it is advisable to use both -XX:CMSInitiatingOccupancyFraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly.
-XX:+UseCMSInitiatingOccupancyOnly
Indicates all concurrent garbage collection CMS cycles should start based on the value of the -XX:CMSInitiatingOccupancyFraction. Generally, it is advisable to use both -XX:CMSInitiatingOccupancyFraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly.
Also see -XX:CMSInitiatingPermOccupancyFraction and -XX:CMSInitiatingOccupancyFraction=<percent>.
-XX:CMSInitiatingPermOccupancyFraction=<percent>
The percent of permanent generation space occupancy at which the first CMS garbage collection cycle should start. Subsequent starts of the CMS cycle are determined at a HotSpot ergonomically computed occupancy. If -XX:+UseCMSInitiatingOccupancyOnly is also specified, it is the percent of permanent generation space occupancy at which all CMS garbage collection cycles should start.
Generally, it is advisable to use both -XX:CMSInitiatingPermOccupancy Fraction=<percent> and -XX:+UseCMSInitiatingOccupancyOnly. Also see -XX:+UseCMSInitiatingOccupancyOnly.
-XX:+CMSClassUnloadingEnabled
Enables concurrent garbage collection of permanent generation. Use -XX:+CMSClassUnloadingEnabled when it is desirable for garbage collection of permanent generation to use CMS.Use of the Java 6 Update 3 or earlier also requires the use of -XX:+CMSPermGenSweepingEnabled.
-XX:+CMSPermGenSweepingEnabled
Enables permanent generation CMS garbage collection sweeping. Only applicable for Java 6 Update 3 or earlier JDKs and when -XX:+CMSClassLoadingEnabled is used.
-XX:+CMSScavengeBeforeRemark
Instructs the HotSpot VM to perform a minor garbage collection prior to executing a CMS remark.A minor garbage collection just prior to a CMS remark can minimize the amount of work for the remark phase by reducing the number of objects that may be reachable from the old generation space into the young generation space.Useful when wanting to reduce the duration of time it takes to complete a CMS cycle, especially a CMS remark.
Also see -XX:+UseConcMarkSweepGC.
-XX:+ScavengeBeforeFullGC
Instructs the HotSpot VM to garbage collect the young generation space before executing a full garbage collection.This is the default behavior for the HotSpot VM. It is generally not advisable to disable this option via -XX:-ScavengeBeforeFullGC since garbage collecting the young generation space before a full garbage collection can reduce the number of objects that may be reachable from the old generation space into the young generation space.
-XX:+ParallelRefProcEnabled
Enables multithreaded reference processing. This option can shorten the amount of time it takes the HotSpot VM to process Reference objects and finalizers.
-XX:+ExplicitGCInvokesConcurrent
Requests the HotSpot VM to execute any explicit GCs, i.e., System.gc() calls, to invoke a CMS cycle rather than a stop-the-world GC. Useful when it is desirable to avoid an explicit stop-the-world full garbage collection. It is generally advisable to use -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses in favor of -XX:+ExplicitGCInvokesConcurrent.Also see -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses.
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
Same as -XX:+ExplicitGCInvokesConcurrent with the addition of unloading of classes from the permanent generation space.It is generally advisable to use the -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses command line option over -XX:+ExplicitGCInvokesConcurrent.
-XX:+DisableExplicitGC
Disables full garbage collections invoked as a result of an explicit call to System.gc(). Useful in applications that explicitly call System.gc() without a known or justified reason to explicitly request a full garbage collection.Also see -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses and -XX:+ExplicitGCInvokesConcurrent.
-XX:+CMSIncrementalMode
Enables the incremental CMS concurrent garbage collector in which the concurrent phases of CMS are done incrementally, periodically stopping the concurrent phase to yield back the processor to application threads. Generally not recommended for multicore systems or large Java heaps.
-XX:+CMSIncrementalPacing
Enables automatic control of the amount of work the incremental CMS collector is allowed to do before giving up the processor, based on application behavior. Use only with -XX:+CMSIncrementalMode.
-verbose:gc
Enables reporting of basic garbage collection information at each garbage collection. Recommend using -XX:+PrintGCDetails over -verbose:gc.
-XX:+PrintGC
Enables reporting of basic garbage collection information at each garbage collection. Reports the same information as -verbose:gc. Recommend using -XX:+PrintGCDetails over -XX:+PrintGC.
-Xloggc:<filename>
Enables reporting of garbage collection statistics to a file with the supplied name for <filename>.A recommended practice is to capture to a log file with a minimum of the output of -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps and -XX:+PrintGCDetails.
-XX:+PrintGCDetails
Enables detailed reporting of garbage collection statistics from young generation, old generation, and permanent generation space. Recommended to use -XX:+PrintGCDetails over -verbose:gc and use -Xloggc:<filename> to capture the data in a log file.
-XX:+PrintGCTimeStamps
Enables the printing of a time stamp at each garbage collection indicating the amount of elapsed time since the JVM launched. Recommended to use -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps with -XX:+PrintGCDetails to provide a context of time when a garbage collection occurred.
-XX:+PrintGCDateStamps
Enables the printing of a localized date and time stamp at each garbage collection indicating the current date and time. Use -XX:+PrintGCDateStamps over -XX:+PrintGCTimeStamps when it is desirable to see wall clock time over a time stamp representing the time since JVM launch. Recommended to use -XX:+PrintGCTimeStamps or -XX:+PrintGCDateStamps with -XX:+PrintGCDetails to provide a context of time when a garbage collection occurred.
-XX:+PrintTenuringDistribution
Enables the reporting of object tenuring statistics including the desired occupancy of survivor spaces to avoid premature tenuring of objects from a survivor space into old generation space, the HotSpot VM’s calculated tenuring threshold, the current maximum tenuring threshold, and an object age histogram showing object ages currently held in the survivor space. Useful to obtain tenuring information and object age information when tuning the young generation’s survivor spaces to control object aging or when objects are tenured to the old generation with the concurrent or serial garbage collector. Advisable to use this option in applications emphasizing low latency and continuously fine-tuning object aging or when objects are promoted from survivor space to old generation space.
-XX:+PrintAdaptiveSizePolicy
Enables the reporting of detailed garbage collection statistics of the throughput garbage collector including information on the number of bytes that have survived a minor garbage collection, how many bytes have been promoted in a minor garbage collection, whether survivor space has overflowed, a time stamp of when the minor garbage collection started, the major cost, mutator cost, the throughput goal, the amount of live space bytes, amount of free space bytes, the previous promotion size, the previous eden size, the desired promotion size, the desired eden size, and the current survivor space sizes. When adaptive sizing is disabled via -XX:-UseAdaptiveSizePolicy, reports only the number of bytes that have survived a minor garbage collection, how many bytes have been promoted in a minor garbage collection, and whether survivor space has overflowed. Useful when disabling adaptive sizing, -XX:-UseAdaptiveSizePolicy. The statistics produced are useful when explicitly fine-tuning the sizes of young generation’s eden and survivor spaces for effective object aging and tenuring of objects from survivor spaces to old generation space. Also see -XX:-UseAdaptiveSizePolicy.
-XX:+PrintGCApplicationStoppedTime
Enables the printing of the amount of time application threads have been stopped as the result of an internal HotSpot VM operation including stop-the-world garbage collections, stop-the-world phases of the CMS garbage collector, and any other safepoint operations. Useful in applications emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationConcurrentTime and -XX:+PrintSafe pointStatistics.
-XX:+PrintGCApplicationConcurrentTime
Enables the printing of the amount of time application threads have been executing concurrently with internal HotSpot VM threads. In other words, the amount of time application threads have been executing between HotSpot VM operations that caused application threads to be stopped. Useful in an application emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationStoppedTime and -XX:+PrintSafepoint Statistics.
-XX:+PrintSafepointStatistics
Enables the printing of HotSpot VM safepoint operations that have occurred and when they occurred. The output is printed at VM exit time. The output contains a line of output for each safepoint that occurred. Each line contains the time since VM launch of the safepoint operation occurred, type of VM operation, current number of threads active in the VM, current number of threads, current number of threads initially running, current number of threads waiting to block, amount of time in milliseconds threads spent spinning, amount of time in milliseconds threads spent blocked, amount of time threads spent in milliseconds synchronizing, amount of time in milliseconds threads spent cleaning, amount of time in milliseconds spent in VM operations, and number of page traps. A summary is printed at the end of the output summarizing the number of different safepoint operations along with a maximum synchronization time in milliseconds and the safepoint operation that took the maximum amount of time. Useful for applications emphasizing low latency and wanting to correlate latency events to HotSpot VM induced latencies as the result of safepoint operations. Also see -XX:+PrintGCApplicationStoppedTime and -XX:+PrintGCAppli cationConcurrentTime.
-XX:+BackgroundCompilation
Instructs the JIT compiler to run as a background task, running the method in interpreter mode until the background compilation is finished. This option is enabled by default in HotSpot VMs. When writing micro-benchmarks, it can be useful to disable background compilation, -XX:-BackgroundCompilation, in an attempt to produce more deterministic behavior of the JIT compiler and more deterministic results of the micro-benchmark. -XX:-BackgroundCompilation, disabling background compilation, is also accomplished with -Xbatch. Also see -Xbatch.
-Xbatch
Disables JIT compiler background compilation, equivalent to -XX:-Background Compilation. Normally the HotSpot VM compiles the method as a background task,running the method in interpreter mode until the background compilation is finished. -XX:-BackgroundCompilation and -Xbatch disable background compilation so that JIT compilation of methods proceeds as a foreground task until completed. When writing micro-benchmarks, it can be useful to disable background compilation in an attempt to get more deterministic behavior of the JIT compiler and more deterministic results of the micro-benchmark. -Xbatch, disabling background compilation, is also accomplished with -XX:-BackgroundCompilation. Also see -XX:+BackgroundCompilation.
-XX:+TieredCompilation
Enables a JIT compilation policy to make initial quick JIT compilation decisions analogous to optimizations made by the HotSpot VM’s -client runtime and then continue to make more sophisticated JIT compilation decisions similar to those made by the VM’s -server runtime for frequently called Java methods in the program. In short, it uses a combination of the best of both -client and -server runtimes, quick compilation along sophisticated optimizations for frequently called Java methods. At the time of this writing, it is not recommended to use this command line option as a replacement for the -server runtime since the -server runtime offers better peak performance. This recommendation may change in the future as the tiered compilation feature is enhanced. Client applications running Java 6 Update 25 or later may consider using this command line option with the -server runtime (-server -XX:+TieredCompilation) as an alternative to the -client runtime. It is recommended you measure application startup performance and application responsiveness to assess whether the -server runtime with -XX:+TieredCompilation is better suited for the application than the -client runtime.
-XX:+PrintCompilation
Enables the printing of JIT compilation information for each method optimized by the HotSpot VM’s JIT compiler.Useful when wanting to know more about JIT compilation activities and in the creation or evaluation of micro-benchmarks.
Description of the output produced is as follows:
<id> <type> <method name> [bci] <(# of bytes)>
where id is
compile id, (uses at least three columns)
— if compiled method is a native method
type is none or more of
% – compile for on stack replacement (osr)
* | n – compiled method is native
s – compiled method is synchronized
! – compiled method has exception handler
b – interpreter blocked until compile completes
1 – compile without full optimization, tier 1 compilation
made not entrant – method deoptimized
made zombie – compiled method no longer valid
method name is
method name without signature
bci is
@ ## – for osr compiles, bytecode index of osr
# of bytes is
(## bytes) – # of bytes of bytecodes in method
Additional information on “made not entrant” and “made zombie”: “made not entrant” and “made zombie” are life cycle states of a JIT compiled method. Live JIT compiled methods are “made not entrant” as a result of executing an uncommon trap in the generated (machine) code. Uncommon traps are used to handle situations such as references to unloaded classes and to recover from some optimistic optimization that made assumptions that later turned out to be invalid. More formally, JIT compiled methods reported as “made not entrant” may still have live activations but are not allowed to run new activations. JIT compiled methods that are reported as “made zombie” are a later life cycle state. It means that there are no live activations of that compiled method. JIT compiled methods can go directly to the zombie state when a class is unloaded since it is known that all methods referencing that class are no longer live. JIT compiled methods reported as “made not entrant” transition to a reported “made zombie” state after the JIT compiler has detected that there no longer exists any live activations for that JIT compiled method. Once the JIT compiler is sure no other compiled method has references to a “made zombie” method, the “made zombie” method is freed. That is, it can be freed from the VM’s code cache where generated code is stored.
It is possible the output from -XX:+PrintCompilation may suggest that a method that is known to be executed frequently by an application has been deoptimized, but the output does not reflect that the method has been reoptimized. This can occur as a side-effect of method inlining done by the JIT compiler. If a frequently executed method is reported as deoptimized and it had been inlined, it is possible the -XX:+PrintCompilation output may not report the method as having been reoptimized.
-XX:+PrintInlining
Reports methods that are inlined or attempted to be inlined along with method byte size in bytecode. Use of -XX:+PrintInlining requires what is known as a HotSpot debug VM. Information from -XX:+PrintInlining can be used to fine-tune -XX:MaxInlineSize=<n>.
-XX:MaxInlineSize=<n>
Sets the maximum bytecode size beyond which a method is not inlined unless there is strong evidence that it should be inlined, such as profile information that suggests the method is a hot method. It is not advisable to use this command line option. Rarely do applications benefit from explicitly setting -XX:MaxInlineSize. Also see -XX:+PrintInlining.
-XX:+PrintOptoAssembly
Reports optimization decisions made by the HotSpot Server JIT compiler including generated assembly. Requires a HotSpot debug Server VM (works only with -server switch on Hot-Spot debug VMs).Useful for understanding and evaluating optimization decisions made by the Server JIT compiler, especially in micro-benchmarks. Generally, using a profiling tool such as Oracle Solaris Studio Performance Analyzer on Oracle Solaris or Linux offers a better way to observe compiler generated code for applications larger than a micro-benchmark. But, it does not offer any information on optimization decisions the compiler made in arriving at the generated assembly code shown in the Performance Analyzer.
-XX:+HeapDumpOnOutOfMemoryError
Enables the generation of a heap dump of the JVM’s heap spaces when an Out-OfMemoryError occurs.The heap dump created in the directory where the JVM is launched having a filename of the form java_pid<JVM process id>.hprof, where <JVM process id> is the process id of the JVM process executing the Java application.Useful when wanting to be able to perform memory usage analysis in the event an OutOfMemoryError occurs in a Java application.Also see -XX:HeapDumpPath=<path>.
-XX:HeapDumpPath=<path>
Sets the directory path to where a heap dump file is created to the path specified as <path>.
Useful when wanting to direct the generation of a heap dump file to a specific directory location.
-XX:OnOutOfMemoryError=<command or set of commands>
Enables the ability for a command or set of commands to be run when the HotSpot VM experiences an OutOfMemoryError. Useful when specific commands or operations are desirable if an OutOfMemory-Error occurs.
-XX:+ShowMessageBoxOnError
Enables an ability to have the HotSpot VM, before it exits, to display a dialog (GUI) box saying it has experienced a fatal error.This command line option essentially prevents the VM from exiting and provides the opportunity to attach a debugger to the VM to investigate the cause of the fatal error. Useful when wanting to diagnose a VM before it exits as a result of a fatal error.
-XX:OnError=<command or set of commands>
Enables the ability to invoke a set of commands when the application experiences an unexpected HotSpot VM exit.Useful when it is desirable to collect specific system information or invoke a debugger such as Oracle Solaris or Linux dbx or Window’s Winddbg to immediately examine the unexpected VM exit.
-Xcheck:jni
Enables an alternative set of debugging interfaces to be used by a Java application using the Java Native Interface to help with debugging issues associated with or introduced by the use of native code in a Java application. The alternative Java Native Interface introduced with this command line option verifies arguments to Java Native Interface calls more stringently, as well as performing additional internal consistency checks.Useful when wanting to confirm a JVM execution issue is not the result of an issue in how Java Native Interface methods are invoked.
-XX:+AggressiveOpts
Enables the latest HotSpot VM performance optimizations.Useful for a Java application in need of all the performance it can find. Performance optimizations when first introduced in the HotSpot VM usually come in under this command line option. After one or more releases, those optimizations are made the default.For application’s where stability or availability of the application is more important than performance, it is not suggested to use this command line option.
-XX:+AggressiveHeap
An encompassing command line option that enables a larger set of aggressive options including, but not limited to Java heap size and configuration or performance features. It is recommended to use -XX:+AggressiveOpts in favor of using -XX:+AggressiveHeap.
-XX:+UseBiasedLocking
Enables biased locking feature. Introduced in Java 5 HotSpot VMs; when enabled, it biases locking to the thread that previously held the lock. In uncontended lock situations, near lock free overhead can be realized.In Java 5 HotSpot VMs -XX:+UseBiasedLocking must be explicitly enabled to use the feature. In Java 6 HotSpot VMs this feature is automatically enabled by default. It must be explicitly disabled, -XX:-UseBiasedLocking, if this feature is not desired with Java 6 HotSpot VMs.Generally useful for most Java applications. Applications that predominately utilize locks in a manner where the thread that acquires a lock is not the same as the thread that acquired it last. An example would be an application where locking activity is dominated by locking activity around worker thread pools and worker threads. In this family of Java applications, since a HotSpot VM safepoint operation is required to revoke bias, it may be beneficial to explicitly disable biased locking, -XX:-UseBiasedLocking.
-XX:+DoEscapeAnalysis
Enables escape analysis optimization feature. An object, after it is allocated by some executing thread “escapes” if some other thread can ever see the allocated object. If an object does not escape, the HotSpot VM Server JIT compiler may perform any or all of the following optimizations:
– Object explosion; allocate an object’s fields in different places and potentially eliminate object allocations.
– Scalar replacement; store scalar fields in CPU registers.
– Thread stack allocation; store object fields in a stack frame.
– Eliminate synchronization.
– Eliminate garbage collection read/write barriers.
-XX:+DoEscapeAnalysis is automatically enabled with -XX:+AggressiveOpts,but otherwise disabled by default in Java 6 updates prior to Java 6 Update 23. Introduced in Java 6 Update 14.Also see -XX:+AggressiveOpts.
-XX:+UseLargePages
Enables use of large memory pages in the HotSpot VM.Automatically enabled on Oracle Solaris platforms. Not automatically enabled on Linux or Windows platforms.Use of -XX:+UseLargePages can reduce TLB (translation lookaside buffer) misses. 32-bit Intel and AMD x86 support 4 megabyte pages.
64-bit Intel and AMD x64 support 2 megabyte pages.Recent 64-bit Intel and AMD x64 supports up to 1 gigabyte pages.
SPARC T-series supports up to 256 megabyte pages with recent T-series supporting up to 2 gigabyte pages.
Oracle Solaris pagesize -a command reports page sizes supported by the underlying hardware. Large page support on Oracle Solaris requires no additional operating system configuration changes.
Linux getconf PAGESIZE or getconf PAGE_SIZE reports the currently configured page size. Linux requires additional operating system setup and configuration. The modifications required can vary depending on the Linux distribution and Linux kernel. It is advisable to consult a Linux administrator or your Linux distribution documentation for the appropriate changes. Windows requires additional operating system setup and configuration. Not all Windows operating systems provide large page support. Also see -XX:LargePageSizeInBytes and -XX:+AlwaysPreTouch.
-XX:LargePageSizeInBytes=<n>[g|m|k]
Enables use of large memory pages in the HotSpot VM with an explicit size. The underlying hardware platform must support the size <n>[g|m|k] page size. Otherwise, its use falls back to its default page size usage.
Useful when explicitly desiring a page size be used, i.e., 1 gigabyte pages on AMD or Intel platforms that support 1 gigabyte pages or 256 megabyte pages on SPARC T-series platforms or 2 gigabyte pages on recent SPARC T-series platforms. Also see -XX:+UseLargePages and -XX:+AlwaysPreTouch.
-XX:+AlwaysPreTouch
Enables the touching of all memory pages used by the JVM heap spaces during initialization of the HotSpot VM, which commits all memory pages at initialization time. By default, pages are committed only as they are needed. In other words, pages are committed as JVM heap space fills.
A garbage collection that copies to survivor space or promotes objects to the old generation space, which necessitates a new page may result in a longer garbage collection pause as a result of zeroing and committing the new page. Note, this additional overhead only occurs the first time there is a need for that additional page. If the HotSpot VM is using large pages in the absence of this command line option, the additional overhead of zeroing and committing the new page may be noticeable in garbage collection times. As a result it can be useful to use -XX:+AlwaysPreTouch when using large pages.
The enabling of -XX:+AlwaysPreTouch increases application startup time. But observing lengthier garbage collection pause times as a result of pages being zeroed and committed as JVM heap space is consumed is less likely.
-XX:+UseNUMA
Enables a JVM heap space allocation policy that helps overcome the time it takes to fetch data from memory by leveraging processor to memory node relationships by allocating objects in a memory node local to a processor on NUMA systems.
Introduced in Java 6 Update 2. As of this writing, it is available with the throughput collector only, -XX:+UseParallelOldGC and -XX:+UseParallelGC.On Oracle Solaris, with multiple JVM deployments that span more than one processor/memory node should also set lgrp_mem_pset_aware=1 in /etc/system.
Linux additionally requires use of the numacntl command. Use numacntl –interleave for single JVM deployments. For multiple JVM deployments where JVMs that span more than one processor/memory node, use numacntl –cpubind=<node number> –memnode=<node number>.
Windows under AMD additionally requires enabling node-interleaving in the BIOS for single JVM deployments. All Windows multiple JVM deployments, where JVMs that span more than one processor/memory node should use processor affinity, use the SET AFFINITY [mask] command. Useful in JVM deployments that span processor/memory nodes on a NUMA system.
-XX:+UseNUMA should not be used in JVM deployments where the JVM does not span processor/memory nodes.
-XX:+PrintCommandLineFlags
Enables the printing of ergonomically selected HotSpot VM settings based on the set of command line options explicitly specified. Useful when wanting to know the ergonomic values set by the HotSpot VM such as JVM heap space sizes and garbage collector selected.
-XX:+PrintFlagsFinal
Enables the printing of all production HotSpot VM command line option names and their corresponding values as they are set by the HotSpot VM based on the command line options explicitly specified and HotSpot VM defaults for options not specified. Introduced in Java 6 Update 19.
Useful when wanting to know the configuration of HotSpot VM options in use by a Java application. In contrast to -XX:+PrintCommandLineFlags, -XX:+PrintFlagsFinal prints all HotSpot VM options and their corresponding values as set by the HotSpot VM, not just those that are ergonomically set.
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
