JavaTM HotSpot VM Options

Document Sample
JavaTM HotSpot VM Options Powered By Docstoc
					Java HotSpot VM Options

See also Performance Docs

This document provides information on the command-line options and environment variables that can affect the performance characteristics of the Java HotSpot Virtual Machine. Unless otherwise noted, all information in this document pertains to both the Java HotSpot Client VM and the Java HotSpot Server VM. The document contains the following sections. Categories of Java HotSpot VM Options Java HotSpot VM Equivalents of Exact VM Options Java HotSpot Equivalents to _JIT_ARGS Environment Variables Java HotSpot Equivalents to _JVM_ARGS Environment Variables Additional Java HotSpot Arguments Java support for Large Memory Pages

Categories of Java HotSpot VM Options
Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Windows, Solaris and Linux. This document deals exclusively with non-standard options recognized by the Java HotSpot VM:


Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the Java 2 SDK. Because the -XX options have specific system requirements for correct operation and may require privileged access to system configuration parameters, they are not recommended for casual use. These options are also subject to change without notice.

Java HotSpot VM Equivalents of Exact VM Options
This section is of interest primarily to users of J2SE 1.3 and 1.4 on Solaris. Prior to version 1.3.0, the production releases of the Java 2 SDK for Solaris shipped with a virtual-machine implementation known as the Exact VM (EVM). Beginning with version 1.3.0, the Exact VM is replaced by the Java HotSpot VM. Some options supported by the Exact VM have changed names or become obsolete in the Java HotSpot VM. These EVM options and their Java HotSpot VM equivalents are given in the following table.

EVM Option -Xt -Xtm -Xoss

Description Instruction tracing

Java HotSpot equivalent None (obsolete option)

Method tracing None (obsolete option) Maximum java None (HotSpot doesn't have separate native stack size and Java stacks) Verify heap integrity -XX:+VerifyBeforeGC -XX:+VerifyAfterGC XX:+VerifyTLE (-XX:+VerifyTLAB in J2SE 1.4) -XX:+VerifyBeforeScavenge XX:+VerifyAfterScavenge (all debug only) -Xmaxjitcodesize<num> (used to be Xmaxjitcodesize=32m, now Xmaxjitcodesize32m) (See section on Xgenconfig below)


Maximum Comiled code Xmaxjitcodesize size -Xgenconfig -Xoptimize Configure the heap

Use optimizing -server JIT Compiler Use concurrent garbage -XX:+UseConcMarkSweepGC (available collector beginning with J2SE 1.4.1) (1.2.2_07+)


The Java HotSpot VM currently recognizes the following -X options that were not supported by the Exact VM. Option -Xincgc -Xnoincgc Use Train GC Do not use Train Garbage Collection (default) Description

heap free percentage (default 70) XX:MaxHeapFreeRatio=<Maximum> -X:MinHeapFreeRation=<Minimum> heap free percentage (default 40) -Xint -XX:+UseBoundThreads -Xmn<Size> -XX:+UseParallelGC Intepreter only (no JIT Compilation) Bind user level threads (Solaris only) Set the size of the young generation (available beginning in J2SE 1.4.0) Use parallel garbage collection (available beginning in J2SE 1.4.1)


On the Solaris operating environment, the VM uses SIGUSR1 by default, which can sometimes conflict with applications that signal-chain SIGUSR1. -XX:+UseAltSigs will cause the VM to use signals other than SIGUSR1 and SIGUSR2 as the default. Available beginning in J2SE 1.4.1 on the Solaris operating environment.

Java HotSpot VM Equivalents to _JIT_ARGS Environment Variables
Most _JIT_ARGS environment variables are internal debugging options only and have no corresponding Java HotSpot options. Most simply turn off some form of optimization which may have caused instability when first introduced and could be used by the internal testing group to track down problems. _JIT_ARGS Environment jit/jbe HotSpot Option Description jbe is the same as -Xoptimize in 1.2 based systems, jit is the default. Use server in 1.3 to replace -Xoptimize (or jbe) in 1.2.


trace V8/V9

traces methods as compiled XX:+PrintCompilation Done autmatically on both systems, force architecture using these flags XX:+UseV8InstrsOnly (Sparc/debug only)

Java HotSpot VM Equivalents _JVM_ARGS Environment Variables
_JVM_ARGS Environment bound_threads HotSpot Option -XX:+UseBoundThreads Description This option forces all threads to be created as bound threads.

Disable young generation resizing. -XX:NewSize=<size> To do this on fixed_size_young_gen -XX:MaxNewSize=<size> for 1.3 HotSpot, simply set -Xmn<size> for 1.4 the size of the young generation to a

constant. gc_stats ims_concurrent -verbose:gc none Integer specifying maximum number of bytecode instructions in a method which gets inlined. Integer specifying maximum number of bytecode instructions in a frequently executed method which gets inlined. Print message about inlined methods (debug only) Turns on various forms of gc statistics gathering.


inline_instrs -XX:FreqInlineSize=<size>

inline_print no_parallel_gc sync_final yield_interval monitor_order

-XX:+PrintInlining none none

(debug only) Interval in milliseconds XX:DontYieldALotInterval=<ms> between yields. none

Additional Java HotSpot arguments
Numbers can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and 'g' or 'G' for gigabytes (for example, 32k is the same as 32768). Turn on a boolean flag with -XX:+<option> and off with -XX:-<option>. Flag and Default -XX:AllowUserSignalHandlers -XX:AltStackSize=16384 -XX:+MaxFDLimit -XX:MaxHeapFreeRatio=70 Description Do not complain if the application installs signal handlers (Solaris Only) Alternate signal stack size (in Kbytes, Solaris Only) Bump the number of file descriptors to max. (Solaris only) Maximum percentage of heap free after GC to avoid shrinking

-XX:MinHeapFreeRatio=40 -XX:-UseBoundThreads -XX:UseLWPSynchronization -XX:+UseThreadPriorities -XX:MaxPermSize=64m -XX:-CITime -XX:PrintTenuringDistribution -XX:TargetSurvivorRatio=50 -XX:+DisableExplicitGC

Minimum percentage of heap free after GC to avoid expansion Bind user level threads to kernel threads (Solaris only) Use LWP-based instead of thread based synchronization. Default is on in J2SE 1.4.0 or higher. (Solaris only) Use native thread priorities Size of the Permanent Generation, see Tuning Garbage Collection with the 5.0 Java™ Virtual Machine Time spent in JIT Compiler (1.4 only) Print tenuring age information Desired percentage of survivor space used after scavenge Disable calls to System.gc(), JVM still performs garbage collection when necessary

Disable young generation GC prior to a full GC XX:+ScavengeBeforeFullGC (on by default in Java SE 5.0 or later) Enable biased locking. Enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines. Some applications with significant amounts of uncontended synchronization may attain significant speedups with this flag enabled; some applications with certain patterns of locking may see slowdowns, though attempts have been made to minimize the negative impact. (available as of Java SE 5 update 6) Enable large pages (on by default for Solaris). For details please see the section Java support for Large Memory Pages



Those flags differing per architecture/OS/JVM Verison. "Flag and Default" has the default of Sparc/-server, JVM version 1.3 Flag and Default -XX:CompileThreshold=10000 Description number of method invocations/branches before (re-)compiling [10,000 -server, 1,500 client] Maximum size of new generation (in bytes) [32m sparc, 2.5m intel for 1.3, no limit for 1.4 as NewRatio is now used to determine MaxNewSize] Ratio of new/old generation sizes [sparc server: 2, sparc -client: 4 (1.3) 8 (1.3.1+), intel: 12] Default size of new generation (in bytes) [sparc 2.125M, intel: 640k] Spin count variable for use with XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (as of J2SE 1.4.2, Linux only)


-XX:NewRatio=2 -XX:NewSize=2228224


Reserved code cache size (in bytes) maximum code cache size. [Solaris 64-bit: XX:ReservedCodeCacheSize=32m 1024m] -XX:SurvivorRatio=64 Ratio of eden/survivor space size [Solaris: 64, Solaris: 32 (on 1.3.1 and later), Linux/Windows: 8] Thread Stack Size (in Kbytes) (0 means use default stack size) [Sparc: 512, Solaris Intel: 256, Sparc 64bit: 1024 all others 0] Use thread-local object allocation [Sparc server: true, all others: false] See Intimate Shared Memory Use Multiple Page Size Support (Solaris 9 only) w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. Sets the large page size used for the Java heap. Set to 2m when running 32-bit JVM on Solaris 10 x86 with AMD64 CPUs. Solaris Only. Defaults (SPARC: 8m, x86: 4m, x86_64: 2m)

-XX:ThreadStackSize=512 -XX:+UseTLE (-XX:+UseTLAB in J2SE 1.4) -XX:-UseISM -XX:-UseMPSS



Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (as of J2SE 1.4.2, Linux only)

Java support for Large Memory Pages
As of Java SE 5.0 there is now a cross-platform flag for requesting large memory pages: -XX:+UseLargePages (on by default for Solaris, off by default for Windows and Linux). The goal of large page support is to optimize processor Translation-Lookaside Buffers. A Translation-Lookaside Buffer (TLB) is a page translation cache that holds the most-recently used virtual-to-physical address translations. TLB is a scarce system resource. A TLB miss can be costly as the processor must then read from the hierarchical page table, which may require multiple memory accesses. By using bigger page size, a single TLB entry can represent larger memory range. There will be less pressure on TLB and memory-intensive applications may have better performance. However please note sometimes using large page memory can negatively affect system performance. For example, when a large mount of memory is pinned by an application, it may create a shortage of regular memory and cause excessive paging in other applications and slow down the entire system. Also please note for a system that has been up for a long time, excessive fragmentation can make it impossible to reserve enough large page memory. When it happens, either the OS or JVM will revert to using regular pages. Operating system configuration changes to enable large pages:

Solaris: As of Solaris 9, which includes Multiple Page Size Support (MPSS), no additional configuration is necessary. Linux: Large page support is included in 2.6 kernel. Some vendors have backported the code to their 2.4 based releases. To check if your system can support large page memory, try the following:
# cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB #


If the output shows the three "Huge" variables then your system

can support large page memory, but it needs to be configured. If the command doesn't print out anything, then large page support is not available. To configure the system to use large page memory, one must log in as root, then: 1. Increase SHMMAX value. It must be larger than the Java heap size. On a system with 4 GB of physical RAM (or less) the following will make all the memory sharable:
# echo 4294967295 > /proc/sys/kernel/shmmax

2. Specify the number of large pages. In the following example 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048k, then 3g = 3 x 1024m = 3072m = 3072 * 1024k = 3145728k, and 3145728k / 2048k = 1536):
# echo 1536 > /proc/sys/vm/nr_hugepages

Note the /proc values will reset after reboot so you may want to set them in an init script (e.g. rc.local or sysctl.conf).

Windows: Only Windows Server 2003 supports large page memory. In order to use it, the administrator must first assign additional privilege to the user who will be running the application: 1. select Control Panel -> Administrative Tools -> Local Security Policy 2. select Local Policies -> User Rights Assignment 3. double click "Lock pages in memory", add users and/or groups 4. reboot the machine

Note the above steps are needed even if it's the administrator who will be running the application, as administrators by default do not have the privilege to lock pages in memory.

Shared By:
Tags: Java, options
Vinothkumar Vinothkumar Engineer