Java -- jvm

softiger

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 Description Java HotSpot equivalent
-Xt Instruction tracing None (obsolete option)
-Xtm Method tracing None (obsolete option)
-Xoss Maximum java stack size None (HotSpot doesn't have separate native and Java stacks)
-Xverifyheap Verify heap integrity -XX:+VerifyBeforeGC -XX:+VerifyAfterGC -XX:+VerifyTLE (-XX:+VerifyTLAB in J2SE 1.4) -XX:+VerifyBeforeScavenge -XX:+VerifyAfterScavenge (all debug only)
-Xmaxjitcodesize Maximum Comiled code size -Xmaxjitcodesize (used to be -Xmaxjitcodesize=32m, now -Xmaxjitcodesize32m)
-Xgenconfig Configure the heap (See section on Xgenconfig below)
-Xoptimize Use optimizing JIT Compiler -server
-Xconcgc Use concurrent garbage collector (1.2.2_07+) -XX:+UseConcMarkSweepGC (available beginning with J2SE 1.4.1)
The Java HotSpot VM currently recognizes the following -X options that were not supported by the Exact VM.
Option Description
-Xincgc Use Train GC
-Xnoincgc Do not use Train Garbage Collection (default)
-XX:MaxHeapFreeRatio= heap free percentage (default 70)
-X:MinHeapFreeRation= heap free percentage (default 40)
-Xint Intepreter only (no JIT Compilation)
-XX:+UseBoundThreads Bind user level threads (Solaris only)
-Xmn Set the size of the young generation (available beginning in J2SE 1.4.0)
-XX:+UseParallelGC Use parallel garbage collection (available beginning in J2SE 1.4.1)
-XX:+UseAltSigs 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 HotSpot Option Description
jit/jbe -client/-server 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 -XX:+PrintCompilation traces methods as compiled
V8/V9 -XX:+UseV8InstrsOnly Done autmatically on both systems, force architecture using these flags (Sparc/debug only)
Java HotSpot VM Equivalents _JVM_ARGS Environment Variables
_JVM_ARGS Environment HotSpot Option Description
bound_threads -XX:+UseBoundThreads This option forces all threads to be created as bound threads.
fixed_size_young_gen -XX:NewSize=
-XX:MaxNewSize= for 1.3
-Xmn for 1.4 Disable young generation resizing. To do this on HotSpot, simply set the size of the young generation to a constant.
gc_stats -verbose:gc Turns on various forms of gc statistics gathering.
ims_concurrent none   
inline_instrs -XX:MaxInlineSize= Integer specifying maximum number of bytecode instructions in a method which gets inlined.
-XX:FreqInlineSize= Integer specifying maximum number of bytecode instructions in a frequently executed method which gets inlined.
inline_print -XX:+PrintInlining Print message about inlined methods (debug only)
no_parallel_gc none   
sync_final none   
yield_interval -XX:DontYieldALotInterval= (debug only) Interval in milliseconds between yields.
monitor_order 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:+ and off with -XX:-.
Flag and Default Description
-XX:-AllowUserSignalHandlers Do not complain if the application installs signal handlers (Solaris Only)
-XX:AltStackSize=16384 Alternate signal stack size (in Kbytes, Solaris Only)
-XX:+MaxFDLimit Bump the number of file descriptors to max. (Solaris only)
-XX:MaxHeapFreeRatio=70 Maximum percentage of heap free after GC to avoid shrinking
-XX:MinHeapFreeRatio=40 Minimum percentage of heap free after GC to avoid expansion
-XX:-UseBoundThreads Bind user level threads to kernel threads (Solaris only)
-XX:-UseLWPSynchronization Use LWP-based instead of thread based synchronization. Default is on in J2SE 1.4.0 or higher. (Solaris only)
-XX:+UseThreadPriorities Use native thread priorities
-XX:MaxPermSize=64m Size of the Permanent Generation,
see Tuning Garbage Collection with the 5.0 Java™ Virtual Machine
-XX:-CITime Time spent in JIT Compiler (1.4 only)
-XX:-PrintTenuringDistribution Print tenuring age information
-XX:TargetSurvivorRatio=50 Desired percentage of survivor space used after scavenge
-XX:+DisableExplicitGC Disable calls to System.gc(), JVM still performs garbage collection when necessary
-XX:+ScavengeBeforeFullGC Disable young generation GC prior to a full GC (on by default in Java SE 5.0 or later)
-XX:+UseBiasedLocking 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 beginning with Java SE 5 update 6)  
-XX:+UseLargePages Enable large pages (on by default for Solaris).
For details please see the section Java support for Large Memory Pages  
-XX:+UseParallelOldGC Use parallel garbage collection for the full collections. Note: this option automatically enables -XX:+UseParallelGC. (available beginning with Java SE 5 update 6)  
-XX:+AggressiveOpts Turns on point performance optimizations from the compiler that are expected to be default in upcoming releases. This is a good flag to test the JVM engineering team's latest performance tweaks that you'll see in upcoming releases. (available beginning with Java SE 5 update 6)  
Those flags differing per architecture/OS/JVM Verison. "Flag and Default" has the default of Sparc/-server, JVM version 1.3 Flag and Default Description
-XX:CompileThreshold=10000 number of method invocations/branches before (re-)compiling [10,000 -server, 1,500 -client]
-XX:MaxNewSize=32m 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]
-XX:NewRatio=2 Ratio of new/old generation sizes [sparc -server: 2, sparc -client: 4 (1.3) 8 (1.3.1+), intel: 12]
-XX:NewSize=2228224 Default size of new generation (in bytes) [sparc 2.125M, intel: 640k]
-XX:PreBlockSpin=10 Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (beginning with J2SE 1.4.2, Linux only)
-XX:ReservedCodeCacheSize=32m Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit: 1024m]
-XX:SurvivorRatio=64 Ratio of eden/survivor space size [Solaris: 64, Solaris: 32 (on 1.3.1 and later), Linux/Windows: 8]
-XX:ThreadStackSize=512 Thread Stack Size (in Kbytes) (0 means use default stack size) [Sparc: 512, Solaris Intel: 256, Sparc 64bit: 1024 all others 0]
-XX:+UseTLE
(-XX:+UseTLAB in J2SE 1.4) Use thread-local object allocation [Sparc -server: true, all others: false]
-XX:-UseISM See Intimate Shared Memory
-XX:-UseMPSS 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.
-XX:LargePageSizeInBytes=2m 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:-UseSpinning Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (beginning with J2SE 1.4.2, Linux only)
Java support for Large Memory Pages
Beginning with 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:
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
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:
select Control Panel -> Administrative Tools -> Local Security Policy
select Local Policies -> User Rights Assignment
double click "Lock pages in memory", add users and/or groups
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.

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/4764/showart_99077.html