SUN JVM option
Disclaimer: Please note that the data presented in this document has been gathered from several publicly available sources. It is a conscious selection of available VM parameters and even though we tried to check most of the facts presented this document may contain errors.
Choosing a VM
Instructs the VM to use the server HotSpot VM. This also implies that default heap sizes and permanent generation sizes are different.
Under 1.5 this option is the default option, if the machine is a server-class machine.
Supported by: 1.3, 1.4, 1.5
Instructs the VM to use the client HotSpot VM. This also implies that default heap sizes and permanent generation sizes are different.
Supported by: 1.3, 1.4, 1.5
Printing Information about GC
Prints out information about garbage collections to standard out. To print the same information to a file, use -Xloggc:<file>
Example:
[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]
See -Xloggc
Supported by: 1.3, 1.4, 1.5
Prints information about garbage collections to the specified file.
In conjunction with -Xloggc this is the best setting for the free GCViewer.
Supported by: 1.4, 1.5
Instructs the VM to be more verbose when printing out garbage collecion data. Specifically it does not only tell you that there was a collection, but also what impact it had on the different generations.
This flag is very useful when tuning generation sizes.
In conjunction with -Xloggc this is the best setting for the free GCViewer.
Example:
2.459: [GC 2.459: [DefNew: 3967K->0K(4032K), 0.0141600 secs] 8559K->7454K(16320K), 0.0143588 secs]
Supported by: 1.4, 1.5
Ensures that timestamps relative to the start of the application are printed in the GC log.
Supported by: 1.4, 1.5
-XX:+PrintTenuringDistribution
Prints details about the tenuring distribution to standard out. It can be used to show this threshold and the ages of objects in the new generation. It is also useful for observing the lifetime distribution of an application.
Example:
5.350: [GC Desired survivor size 32768 bytes, new threshold 1 (max 31)
- age 1: 57984 bytes, 57984 total
- age 2: 7552 bytes, 65536 total
756K->455K(1984K), 0.0097436 secs]
Supported by: 1.3, 1.4, 1.5
Sizing Heap and Generations
Overall maximum heap size. You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xmx256m sets the maximum heap size to 256mb
Supported by: 1.3, 1.4, 1.5
Minimum heap size. You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xms256m sets the minimum heap size to 256mb
Supported by: 1.3, 1.4, 1.5
Sets the size of the young generation. You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xmn64m sets the young generation size to 64mb
Supported by: 1.4, 1.5
-XX:MinHeapFreeRatio=<minimumInPercent>
Sets the minimal percentage of free heap memory that has to be available after a collection. This parameter can be used to influence when the VM is going to request more memory.
Example:
-XX:MinHeapFreeRatio=70
See -XX:MaxHeapFreeRatio
Supported by: 1.3, 1.4, 1.5
-XX:MaxHeapFreeRatio=<maximumInPercent>
Sets the maximal percentage of free heap memory that must at most be available after a collection. This parameter can be used to influence when the VM is going to lower its footprint. In other words it can shrink the heap and therefore memory consumption.
Example:
-XX:MaxHeapFreeRatio=20
See -XX:MinHeapFreeRatio
Supported by: 1.3, 1.4, 1.5
Sets the ratio between young and old generation.
Example:
-XX:NewRatio=3 means that the ratio between the young and old
generation is
eden and the survivor spaces will be one fourth of the
heap.
See -XX:NewSize and -XX:MaxNewSize
Supported by: 1.3, 1.4, 1.5
Sets minimum size of the young generation.
Example:
-XX:NewSize=64m sets the minimum size of the young
generation to 64mb
See -XX:NewRatio and -XX:MaxNewSize
Supported by: 1.3, 1.4, 1.5
Sets maximum size of the young generation.
Example:
-XX:NewSize=64m sets the maximum size of the young
generation to 64mb
See -XX:NewRatio and -XX:NewSize
Supported by: 1.3, 1.4, 1.5
Sets size of the survivor spaces in relation to eden.
Example:
-XX:SurvivorRatio=6 sets the ratio between each survivor space
and eden to be
Supported by: 1.3, 1.4, 1.5
Sets the initial size of the permanent generation (where classes etc. are stored). This can be useful for application servers using many EJBs and JSPs.
Example:
-XX:PermSize=64m
See -XX:MaxPermSize
Supported by: 1.3, 1.4, 1.5
Sets the maximum size of the permanent generation (where classes etc. are stored). This can be useful for application servers using many EJBs and JSPs.
Example:
-XX:MaxPermSize=64m
See -XX:PermSize
Supported by: 1.3, 1.4, 1.5
Choosing and Configuring a Collector
Use parallel garbage collection. This collector is also referred to as the throughput collector. It uses a parallel version of the young generation collector. The old (tenured) generation is still cleaned with the default collector.
Under 1.5 this option is the default option, if the machine is a server-class machine.
This option can not be used in conjunction with -XX:+UseConcMarkSweepGC.
Supported by: 1.4.1, 1.5
-XX:ParallelGCThreads=<number>
Specifies the number of threads used in parallel garbage collection when -XX:+UseParallelGC is set. By default a system with N CPUs uses N garbage collection threads.
Example:
-XX:ParallelGCThreads=4
Supported by: 1.4.1, 1.5
Instructs the VM to try to keep garbage collection pauses shorter than the specified value in ms.
This option applies in conjunction with -XX:+UseParallelGC and has higher priority than -XX:GCTimeRatio.
Example:
-XX:MaxGCPauseMillis=10
Supported by: 1.5
Sets a throughput goal for the VM. The ratio of garbage collection time to application time is 1/(1+<ratio>).
This option applies in conjunction with -XX:+UseParallelGC and has lower priority than -XX:MaxGCPauseMillis.
Example:
-XX:GCTimeRatio=19 sets a goal of 5% of the total time for
garbage collection.
Supported by: 1.5
Instructs the VM to keep track of some statistics and resize both the young and the old (tenured) generation based on the collected data.
This feature is on by default when the option -XX:+UseParallelGC is used.
Supported by: 1.4.1, 1.5
Instructs the JVM to push memory use to the limit. It inspects the machine resources (size of memory and number of processors) and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs. This option is recommended for dedicated server machines.
The physical memory on the machines must be at least 256MB before AggressiveHeap can be used.
Beginning with JVM 1.3.1_02 some GC activity is done in parallel.
Beginning with JVM 1.4 this option implies -XX:+UseParallelGC and -XX:+UseAdaptiveSizePolicy.
Supported by: 1.3, 1.4, 1.5
Use concurrent garbage collection. This collector is also referred to as the concurrent low pause collector. It collects garbage in the old (tenured) generation concurrently to executing the application.
Note that this option can not be used in conjunction with -XX:+UseParallelGC. Instead you may combine it with -XX:+UseParNewGC
Supported by: 1.4.1, 1.5
If the -XX:+UseParNewGC option is in use the remark pauses may be decreased with the -XX:+CMSParallelRemarkEnabled option.
Supported by: 1.4.1, 1.5
Instructs the VM to use a parallel collector for the young generation. This option should be used in conjunction with -XX:+UseConcMarkSweepGC.
Supported by: 1.4.1, 1.5
Activates the train garbage collector. Note that development for this collector has been stopped since 1.4.2.
See -Xincgc
Supported by: 1.3, 1.4, 1.5
Activates the incremental (also called train) garbage collector.
See -XX:+UseTrainGC
Supported by: 1.3, 1.4, 1.5
Miscellaneous Settings
Sets the size of the stack. In a server system with many threads lowering the stack size may be advantageous to reduce footprint. If the stack is too small, you will start seeing StackOverflowErrors.
You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xss128k sets the stack size to 128kb
Supported by: 1.3, 1.4, 1.5
Disables calls to java.lang.System.gc().
-XX:SoftRefLRUPolicyMSPerMB=<ms per mb>
Sets the rate at which the VM clears soft references. The rate is expressed in ms per free mb of heap. For the server VM free heap means potentially free heap using the maximum heap size as set with -Xmx in the calculation. For the client VM the free heap is calculated using the actual current heap size.
Example:
-XX:SoftRefLRUPolicyMSPerMB=1000 instructs the VM to allow
softly reachable objects to remain alive for 1s per free mb
Supported by: 1.3.1, 1.4, 1.5
Java 5.0 (1.5) defines a class of machines referred to as server-class machines. These are machines that have 2 or more physical processors and 2 or more gb of physical memory. On server-class machines the Sun JVM starts with altered default settings. These are:
-server -XX:+UseParallelGC
Additionally the initial heap size (-Xms) is set to 1/64 of the physical memory, up to 1gb. The maximum heap size (-Xmx) is set to 1/4 of the physical memory, up to 1gb.
Note that on server-class 32bit-Windows systems the VM will nevertheless start with the classic client settings, as most 32bit-Windows Java applications are not server applications.