]]>
涓嬮潰鍒楀嚭浜嗗悇涓巶鍟嗙殑杈撳嚭錛屽彲浠ョ湅鍒癐BM鐨勫府鍔╂渶璇︾粏鑰屼笖鏄腑鏂囩殑錛屾湁鎰忔濄?/p>
鍙﹀JRockit榪樻敮鎸佷竴涓?-XX鍙傛暟錛屽叾杈撳嚭濡備笅錛?/p>
Global:
UnlockDiagnosticVMOptions = false (default, writeable)
- Enable processing of flags relating to field diagnostics
UnlockInternalVMOptions = false (default)
- Enable processing of internal, unsupported flags
Class:
FailOverToOldVerifier = true (default, writeable)
- Fail over to old verifier when split verifier fails
UseVerifierClassCache = true (default)
- Try to cache java.lang.Class lookups for old verifier.
UseClassGC = true (default)
(Alias: -Xnoclassgc)
- Allow GC of Java classes
Threads:
UseThreadPriorities = false (default)
- Use native thread priorities
DeferThrSuspendLoopCount = 4000 (default, writeable)
- Number of iterations in safepoint loop until we try blocking
SafepointSpinBeforeYield = 2000 (default, writeable)
- Number of iterations in safepoint loop until we yield instead
of pause (MP only)
UseCompilerSafepoints = true (default)
- Insert safepoint polls in compiled code
DeferPollingPageLoopCount = -1 (default)
- Number of iterations in safepoint loop before arming
safepoint poll page
UseMembarForTransitions = false (default)
- Use membar to serialize thread states.
UseNativeLockProfiling = false (default)
- Profile use of internal JVM monitors
JNI:
CheckJNICalls = false (default)
- Verify all arguments to JNI calls
AbortOnFailedJNICheck = true (default)
- Used with CheckJNICalls. If true, abort the JVM upon first
JNI parameter error.
ErrorOnFailedJNICheck = false (default)
- Used with CheckJNICalls. If true, any errors will be
signalled through a java.lang.Error.
JDK:
UseNewHashFunction = false (default)
- Use HashMaps new hash function on jdks that does not do so by
default
TreeMapNodeSize = 64 (default)
- Size of entry array in each java.util.TreeMap node
MaxDirectMemorySize = 0 (default)
- Maximum total size of NIO direct-buffer allocations
UseLazyStackTraces = true (default)
- Generate stacktraces lazily for thrown Exceptions
ShowInternalMethodsInStackTrace = false (default, writeable)
- Show JVM internal code in java stacktraces.
OS:
ReduceSignalUsage = false (default)
(Alias: -Xrs)
- Reduce the use of OS signals in Java and/or the VM
MaxRecvBufferSize = 65536 (default)
- Maximum size of byte buffer sent to recv
MaxLargePageSize = 0 (default)
- Use value as maximum size for large pages (if possible).
GC:
UseLowAddressForHeap = true (default)
- Use low 4Gb address space for Java heap if possible.
UseLargePagesForHeap = false (default)
- Attempt to use large page translation for the Java heap.
ForceLargePagesForHeap = false (default)
- Force the use of large page translation for the Java heap.
CompressedRefs = false (default)
(Alias: -XXcompressedRefs)
- Use 32-bit java references on 64-bit OS - implies a heap
maximum of 4Gb (probably less)
InitialHeapSize = 0 (default)
(Alias: -Xms)
- Initial size of Java Object heap
MaxHeapSize = 0 (default)
(Alias: -Xmx)
- Maximum size of Java Object heap
GCTimeRatio = 19 (default)
- The ratio of time spent in garbage collection compared to
outside of garbage collection.
GCTimePercentage = 0.000000 (default)
- The percentage of time spent in garbage collection of total
run time.
GCTrigger = 0 (default)
(Alias: -XXgcTrigger)
- The threshold of free heap before a concurrent GC is started
ForceEarlyOC = true (default)
- Force an early OC before old space is empty to avoid
promotion failed.
ForceEarlyOCMaxPercentage = 5.000000 (default)
- Maximum percentage of heap that is allowed to have left
before doing an early OC.
ForceYCOnLargeAllocationFailed = false (default)
- Force YC on a large allocation failure.
UseNurseryEvacuation = false (default)
- Try to evacuate the nursery when a promotion failed has
occured.
DisableEvacuationToNursery = false (default)
- Disallows evacuation to move objects to where the nursery is.
SemiRefPostponedPacketSize = 492 (default)
- The number of references in a postponed semiref packet.
SemiRefPrefetchDistance = 0 (default)
- The number of reference packet indexes to prefetch, or 0 for
no prefetch.
FinalHandleParallelThreshold = -1 (default)
- The minimum number of final handles needed to process them in
parallel.
FinalHandlePacketSize = 200 (default)
- The number of handles in a final handle packet.
MaximumNurseryPercentage = 95 (default)
- Sets the maximum size of the nursery relative to the amount
of free heap after the last old collection.
AllowYCDuringOC = true (default)
- Allow young collections during old collections.
YcAlignAll = false (default)
- Align all objects (with regards to YcAlignMaxSpill) during YC
YcAlignMaxSpill = 40 (default)
- Max spill allowed when aligning objects during YC.
FullSystemGC = false (default)
(Alias: -XXfullSystemGC)
- Always run full GC (with full compaction) when System.gc() is
called
AllowSystemGC = true (default)
(Alias: -XXnoSystemGC)
- Run a GC when System.gc() is called
GcCardTableParts = 1024 (default)
- Initial number of parts of the card table array
GcBalancePrefetchDistance = 4 (default)
- Prefetch distance in a GC balance system workpacket
GcBalancePacketSize = 493 (default)
- Packet size of GC balance system workpackets
NumGenConPrecleaningIterations = 3 (default)
- Number of precleaning iterations for gencon.
AllowEmergencyParSweep = true (default)
- Allow the OC to temporarily change concurrent sweep to
parallel if needed.
TlaWasteLimit = 0 (default)
(Alias: -XXlargeObjectLimit)
- Internal. Use -XXtlaSize:wasteLimit instead.
TlaMinSize = 0 (default)
(Alias: -XXminBlockSize)
- Internal. Use -XXtlaSize:min instead.
TlaPreferredSize = 0 (default)
- Internal. Use -XXtlaSize:preferred instead.
GC::Compaction:
UseFullCompaction = false (default)
- All compactions will be full compactions. Internal. Use
-XXcompaction:full instead.
InternalCompactionPercentage = -1.000000 (default)
- The percentage of the heap to compact for internal
compaction. Internal. Use -XXcompaction:internalPercentage
instead.
ExternalCompactionPercentage = -1.000000 (default)
- The percentage of the heap to compact for external
compaction. Internal. Use -XXcompaction:externalPercentage
instead.
InitialCompactionPercentage = -1.000000 (default)
- The initial percentage of the heap to compact, for both
internal and external compaction. Internal. Use
-XXcompaction:initialPercentage instead.
UseCompaction = true (default)
- Use compaction to reduce fragmentation. Internal. Use
-XXcompaction:enable instead.
UseAbortableCompaction = false (default)
- The compactions should be possible to abort. Internal. Use
-XXcompaction:abortable instead.
NumCompactionHeapParts = 4096 (default)
(Alias: -XXheapParts)
- The number of heap parts in compaction heuristics. Internal.
Use -XXcompaction:heapParts instead.
InitialExternalReservedHeap = 4M (default)
- The initial size of the memory reserved by external
compaction. Internal. Use
-XXcompaction:initialExternalReservedHeap instead.
UseFixedExternalReservedHeap = false (default)
- The size of the memory reserved by external compaction is
fixed. Internal. Use
-XXcompaction:externalReservedHeapIsFixed instead.
MaxCompactionReferences = 0 (default)
(Alias: -XXcompactSetLimit)
- The maximum number of references to store in compaction
before skipping. Internal. Use -XXcompaction:maxReferences
instead.
MaxCompactionReferencesPerObject = 0 (default)
(Alias: -XXcompactSetLimitPerObject)
- The maximum number of references to store per object in
compaction. Internal. Use
-XXcompaction:maxReferencesPerObject instead.
InternalCompactionParts = -1 (default)
(Alias: -XXinternalCompactRatio)
- Deprecated. Use -XXcompaction:internalPercentage instead.
ExternalCompactionParts = -1 (default)
(Alias: -XXexternalCompactRatio)
- Deprecated. Use -XXcompaction:externalPercentage instead.
Object allocation:
UseAllocPrefetch = true (default)
- Use prefetch on object allocation
RedoAllocPrefetch = true (default)
- Do prefetch on object allocation from start of the allocated
object
AllocPrefetchLineLength = -1 (default)
- Line length for allocation prefetch
AllocPrefetchDistance = -1 (default)
- Distance for allocation prefetch
AllocChunkSize = -1 (default)
- Size of chunks to clear/prefetch
Javalock:
UseLockProfiling = false (default)
- Enable Java lock profiling.
ThinLockContendedSpinCount = -1 (default)
- Number of spins between each poll when acquiring a thin lock
ThinLockContendedPollCount = -1 (default)
- Number of polls between each short nap when acquiring a thin
lock
ThinLockConvertToFatThreshold = -1 (default)
- Number of of short naps before converting thin lock to fat
FatLockContendedSpinCount = -1 (default)
- Number of spins between each poll when acquiring a fat lock
FatLockContendedPollCount = -1 (default)
- Number of polls between each short nap when acquiring a fat
lock
MonitorContendedSpinCount = -1 (default)
- Number of spins between each poll when acquiring a monitor
lock
MonitorContendedPollCount = -1 (default)
- Number of polls between each short nap when acquiring a
monitor lock
UseFatLockDeflation = true (default)
- Try to deflate fat locks to thin
FatLockDeflationThreshold = 50 (default)
- Number of uncontended entries on lock before deflation occurs
UseLockQueueLength = true (default)
- Make threads go to sleep if contention exceeds # cpus
UseFatSpin = true (default)
(Alias: -XXdisableFatSpin)
- Should we spin-try then acquiring a fat lock
UseAdaptiveFatSpin = false (default)
- Should we use adaptive spinning acquiring a fat lock
UseThreadContentionMonitoring = true (default)
- Allow thread contention monitoring
JavaLock::LazyUnlocking:
UseLazyUnlocking = true (default)
(Alias: -XXlazyUnlocking)
- Enable lazy unlocking
UseLazyUnlockingInJIT = true (default)
- Use lazy locks in JIT code
UseLazyUnlockingClassBan = true (default)
- Use class banning
UseLazyUnlockingTransferClassBan = true (default)
- Use transfer class banning
JFR:
FlightRecorder = true (default)
- Enable flightrecorder
FlightRecorderOptions = (null) (default)
- Flight recorder arguments
StartFlightRecording = (null) (default)
- Start a Flight recording with args. Equivalent to using
"start_flightrecording".
Code memory:
CodeBlockAbsorbtionSize = 16 (default)
- Maximum extra size allowed for fitting code memory chunks
FreeEmptyCodeBlocks = true (default)
- Free unused code memory
UseLargePagesForCode = false (default)
- Attempt to use large page translation compiled code.
MaxCodeMemory = 0 (default)
- Maximum amount of memory used for generated code
ReserveCodeMemory = false (default)
- Reserve all memory for code at startup
UseCodeGC = true (default)
- Allow GC of discarded compiled code
CodeGCThreshold = 0 (default)
- Released byte threshold for initiating a code GC
CodeGCReclaimThreshold = 0 (default)
- Released byte threshold before compiler attempts to reclaim
unused code space
CodeGCUseReclaim = true (default)
- Should Code GC attempt reclamation of unused code memory
Compiler broker:
MaxOptQueueLength = 0 (default)
- Maximum allowed optimization queue length before JIT thread
helps generate code
OptThreads = 1 (default)
- Number of background optimization threads
JITThreads = 1 (default)
- Number of background JIT threads
JITThreadPrio = 5 (default)
- Priority of background JIT threads
OptThreadPrio = 5 (default)
- Priority of background optimization threads
DisableOptsAfter = -1 (default)
(Alias: -Xnoopt)
- Disable optimizations after n seconds
Compiler:
PreOpt = false (default)
- Optimize all code on jit (first generation)
UseCallProfiling = false (default)
- Use call profiling on unoptimized code
StrictFP = false (default)
(Alias: -Xstrictfp)
- Force strict FP for all methods
CheckStacks = false (default)
(Alias: -Xcheckedstacks)
- Do explicit checks for stack overflow
DevirtualizeAlways = false (default)
- Forces devirtualization in jitted code
UseStringCache = false (default)
- Cache common arrays used in String constructor
MethodCodeAlignment = 32 (default)
- Byte alignment for start of method code
UseInlineObjectAlloc = true (default)
- Generate inlined object allocation code.
UseOldLockMatching = false (default)
- Compatibility mode lock matching
JVMTI:
JavaDebug = false (default)
(Alias: -Xdebug)
- Enable java debugging
Management:
DisableAttachMechanism = false (default)
- Disable mechanism that allows tools to attach to this VM
CrashOnOutOfMemoryError = false (default, writeable)
- Crash JVM process on OutOfMemory
ExitOnOutOfMemoryError = false (default, writeable)
- Terminate JVM process on OutOfMemory
ExitOnOutOfMemoryErrorExitCode = 51 (default, writeable)
- Exit code for termination of JVM process on OutOfMemory
HeapDiagnosticsOnOutOfMemoryError = false (default, writeable)
- Print Java heap diagnostics on OutOfMemory
HeapDiagnosticsPath = (null) (default, writeable)
- When HeapDiagnosticsOnOutOfMemoryError is on, the path
(filename or directory) of the dump file (defaults to
jrockit_<pid>.oomdiag in the working directory)
HeapDumpOnOutOfMemoryError = false (default, writeable)
- Dump Java heap to a hprof binary format file on OutOfMemory
HeapDumpOnCtrlBreak = false (default)
- Dump heap to file in Ctrl-Break handler
HeapDumpPath = (null) (default, writeable)
- When HeapDumpOnOutOfMemoryError is on, the path (filename or
directory) of the dump file (defaults to jrockit_<pid>.hprof
in the working directory)
SegmentedHeapDumpThreshold = 2G (default, writeable)
- Generate a segmented heap dump (JAVA PROFILE 1.0.2 format)
when the heap usage is larger than this
HeapDumpSegmentSize = 1G (default)
- Approximate segment size when generating a segmented heap
dump
StartMemleakOnPort = 0 (default, writeable)
(Alias: -XXmemleak)
- Listen for memleak connections on this port (0 for default)
FlightRecordingDumpOnUnhandledException = false (default, writeable)
- Generate a Flight Recording dump when a thread is terminated
due to an unhandled exception
FlightRecordingDumpPath = (null) (default, writeable)
- When FlightRecordingDumpOnUnhandledException is on, the path
(filename or directory) of the dump file (defaults to
jrockit_<pid>_<thread id>.jfr in the working directory)
Runtime:
AbortOnCrash = false (default, writeable)
- Abort the JVM in case of an crash.
DumpOnCrash = true (default, writeable)
- Generate a dump of the JVM state in case of a crash.
CoreOnCrash = true (default, writeable)
- Generate a core dump file of the JVM state in case of a
crash.
WaitOnCrash = false (default, writeable)
- Wait for user debugger attach in case of a crash.
AbortOnAssert = true (default, writeable)
- Abort JVM on assertion
CrashOnAssert = false (default, writeable)
- Crash dump the JVM on assertion
WaitOnAssert = false (default, writeable)
- Spin and wait JVM on assertion
NumaMemoryPolicy = (null) (default)
- Numa memory policy (interleave, preferredlocal, strictlocal)
BindToNumaNodes = (null) (default)
- Bind process to Numa nodes
BindToCPUs = (null) (default)
- Bind process to CPUs
UseFastTime = true (default)
- Force/disable usage of hardware platform support for fast
time
UseJNIPinning = true (default)
- Use pinning for Objects in call to GetPrimitiveArrayCritical
etc
|
涓嬮潰鏄?X鐨勮緭鍑猴細
SUN JDK 6
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
The -X options are non-standard and subject to change without notice.
|
JRockit JDK 6
-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
-Xgcprio:[throughput|pausetime|deterministic]
sets priority for the garbage collector (gc)
throughput optimizes the gc behavior to achieve optimal
throughput (default in server mode)
pausetime optimizes the gc behavior to achieve minimal
pause times
deterministic optimizes the gc behavior to ensure extremely
short pause times and limit the total number of
those pauses within a prescribed window (this
feature requires a valid license)
-Xgc:[singlecon|gencon|singlepar|genpar]
used to set a static garbage collector
will override the -Xgcprio option
singlecon use the single-spaced concurrent garbage
collection algorithm (default in client mode)
gencon use the generational concurrent
garbage collection algorithm
singlepar use the single-spaced parallel
garbage collection algorithm
genpar use the generational parallel
garbage collection algorithm
-Xms<size>[g|G|m|M|k|K]
sets the initial Java heap size (ms)
server mode: the default value is 25% of the amount
of free physical memory in the system
up to 64 MB with a minimum of 8 MB (default)
client mode: the default value is 25% of the amount
of free physical memory in the system
up to 16 MB with a minimum of 8 MB
-Xmx<size>[g|G|m|M|k|K]
sets the maximum Java heap size (mx)
server mode: the default value is the smallest of 75% of
physical memory and 1536 MB (default)
client mode: the default value is the smallest of 75% of
physical memory and 64 MB
-Xns<size>[g|G|m|M|k|K]
sets the initial Java nursery size for generational collectors
server mode: the default value is dynamic (throughput
prio and genpar gc) or 10 MB per hardware
thread (pausetime prio and gencon gc)
client mode: the default value is 2 MB
-Xss<size>[g|G|m|M|k|K]
set initial stack size
-Xpausetarget=<optimal_pause_time>[ms|s]
JRockit will optimize the pause time to the given target,
uses -Xgcprio:pausetime
ms pause time specified in milliseconds (default)
s pause time specified in seconds
-Xnoclassgc
disable class garbage collection
-Xdebug
enables debugging support in the VM
-Xrun<library>
loads and runs a library
-Xmanagement
enable the management agent
-Xnoopt
do not optimize code
-Xstrictfp
always use strict floating point calculations
-Xverify
do full bytecode verification
-Xnohup or -Xrs
JRockit will not process CTRL_LOGOFF_EVENT or SIGHUP events
-Xverbose[:memory|load|jni|cpuinfo|codegen|opt|gcpause|gcreport]
Enables verbose output. These are only a few of the
available log modules. For more information on log
modules refer to the documentation.
-Xverboselog:<file>
logs verbose output to a file
-Xverbosetimestamp
adds a timestamp to the verbose printout
-Xverbosedecorations:<decorations>
adds <decorations> to the verbose printout
-Xcheck:jni
perform additional checks for JNI functions
For more information on these options refer to the documentation.
The -X options are non-standard and subject to change without notice.
|
IBM JDK 6
浠ヤ笅閫夐」鏄潪鏍囧噯閫夐」錛屽彲闅忔椂鏇存敼錛岃屼笉鍙﹁閫氱煡銆?
-Xbootclasspath:<path> 灝嗗紩瀵肩被璺緞璁劇疆涓?<path>
-Xbootclasspath/p:<path> 灝?<path> 闄勫姞鍦ㄥ紩瀵肩被璺緞鍓嶉潰
-Xbootclasspath/a:<path> 灝?<path> 闄勫姞鍒板紩瀵肩被璺緞鍚庨潰
-Xrun<library>[:options] 瑁呭叆鏈満浠ｇ悊紼嬪簭搴?
錛堜笉鎺ㄨ崘錛岃禐鎴愪嬌鐢?-agentlib錛?
-Xshareclasses[:options] 鍚敤綾繪暟鎹叡浜紙浣跨敤甯姪鑾峰彇璇︾粏淇℃伅錛?
-Xint 浠呰繍琛屽凡瑙ｉ噴鐨勶紙絳夊悓浜?-Xnojit -Xnoaot錛?
-Xnojit 紱佺敤 JIT
-Xnoaot 涓嶈繍琛岄緙栬瘧浠ｇ爜
-Xquickstart 閫氳繃寤惰繜浼樺寲鏉ュ噺灝戝惎鍔ㄦ椂闂?
-Xfuture 鍚敤鏈涓ユ牸鐨勬鏌ワ紝棰勬祴鏈潵鐨勭己鐪佸?
-verbose[:{class|gcterse|gc|dynload|sizes|stack|debug}]
-Xtrace[:option,...] 鎺у埗璺熻釜浣跨敤 -Xtrace:help 浠ヨ幏鍙栨洿澶氳緇嗕俊鎭?
-Xcheck[:option[:...]] 鎺у埗媯鏌ヤ嬌鐢?-Xcheck:help 浠ヨ幏鍙栨洿澶氳緇嗕俊鎭?
浠ヤ笅閫夐」鐨勫弬鏁頒互瀛楄妭涓哄崟浣嶃?
甯︽湁鍚庣紑鈥渒鈥濓紙鍗冿級鎴栤渕鈥濓紙鍏嗭級鐨勫間細榪涜鐩稿簲鐨勮綆椼?
-Xmca<x> 灝?RAM 綾繪澧為噺璁劇疆涓?<x>
-Xmco<x> 灝?ROM 綾繪澧為噺璁劇疆涓?<x>
-Xmn<x> 灝嗗垵濮嬶紡鏈澶ф柊絀洪棿澶у皬璁劇疆涓?<x>
-Xmns<x> 灝嗗垵濮嬫柊絀洪棿澶у皬璁劇疆涓?<x>
-Xmnx<x> 灝嗘渶澶ф柊絀洪棿澶у皬璁劇疆涓?<x>
-Xmo<x> 灝嗗垵濮嬶紡鏈澶ф棫絀洪棿澶у皬璁劇疆涓?<x>
-Xmos<x> 灝嗗垵濮嬫棫絀洪棿澶у皬璁劇疆涓?<x>
-Xmox<x> 灝嗘渶澶ф棫絀洪棿澶у皬璁劇疆涓?<x>
-Xmoi<x> 灝嗘棫絀洪棿澧為噺璁劇疆涓?<x>
-Xms<x> 灝嗗垵濮嬪唴瀛樺ぇ灝忚緗負 <x>
-Xmx<x> 灝嗗唴瀛樻渶澶уぇ灝忚緗負 <x>
-Xmr<x> 灝嗚浣忕殑闆嗗悎澶у皬璁劇疆涓?<x>
-Xmrx<x> 灝嗚浣忕殑闆嗗悎鐨勬渶澶уぇ灝忚緗負 <x>
-Xmso<x> 灝嗘搷浣滅郴緇熺嚎紼嬪爢鏍堝ぇ灝忚緗負 <x>
-Xiss<x> 灝嗗垵濮?java 綰跨▼鍫嗘爤澶у皬璁劇疆涓?<x>
-Xssi<x> 灝?java 綰跨▼鍫嗘爤澧為噺璁劇疆涓?<x>
-Xss<x> 灝嗘渶澶?java 綰跨▼鍫嗘爤澶у皬璁劇疆涓?<x>
-Xscmx<x> 灝嗘柊鍏變韓綾婚珮閫熺紦瀛樼殑澶у皬璁劇疆涓?<x>
-Xscminaot<x> 灝嗕負 AOT 鏁版嵁淇濈暀鐨勬渶灝忓叡浜被楂橀熺紦瀛樼┖闂磋緗負 <x>
-Xscmaxaot<x> 灝嗗厑璁哥敤浜庡瓨鍌?AOT 鏁版嵁鐨勬渶澶у叡浜被楂橀熺紦瀛樼┖闂磋緗負 <x>
-Xmine<x> 灝嗗爢鎵╁睍鐨勬渶灝忓ぇ灝忚緗負 <x>
-Xmaxe<x> 灝嗗爢鎵╁睍鐨勬渶澶уぇ灝忚緗負 <x>
浠ヤ笅閫夐」鐨勫弬鏁頒互 0 鑷?1 鐨勫皬鏁拌〃紺恒?
鍊間負 0.3 琛ㄧず璇鋒眰鐧懼垎姣斾負 30%
-Xminf<x> GC 涔嬪悗鑷敱鍫嗙殑鏈灝忕櫨鍒嗘瘮
-Xmaxf<x> GC 涔嬪悗鑷敱鍫嗙殑鏈澶х櫨鍒嗘瘮
浠ヤ笅閫夐」鐨勫弬鏁頒互灝忔暟琛ㄧず銆?
-Xgcthreads<x> 璁劇疆 GC 綰跨▼鐨勬暟閲?
-Xnoclassgc 紱佺敤鍔ㄦ佺被鍗歌
-Xclassgc 鍚敤鍔ㄦ佺被鍗歌
-Xalwaysclassgc 鍚敤姣忎釜 GC 鐨勫姩鎬佺被鍗歌
-Xnocompactexplicitgc 紱佺敤緋葷粺 GC 鐨勫帇緙?
-Xcompactexplicitgc 鍚敤姣忎釜緋葷粺 GC 鐨勫帇緙?
-Xcompactgc 鍚敤鍘嬬緝
-Xnocompactgc 紱佺敤鍘嬬緝
-Xlp 鍚敤澶ч〉闈㈡敮鎸?
-Xrunjdwp:<options> 鍚敤璋冭瘯錛孞DWP 鏍囧噯閫夐」
-Xjni:<options> 璁劇疆 JNI 閫夐」
|
]]>
JRockit GC in Action
In this article I would like to elaborate on the garbage collection specifics of Oracle's JRockit JVM. Recently JRockit has been made free for use and many people may consider using it instead of another widely popular Oracle JVM - HotSpot (former Sun's JVM). I have more experience with HotSpot JVM, so my opinion may be biased a little, but I will try to stick to the facts as much as I can.
Disclaimer: This article expresses my personal opinion based on my practical experience with JRockit and HotSpot JVMs. My experience is limited by few use cases. Conclusions from this article may not be valid for other use cases. I'm not pretending that I have completed comprehensive research of JRockit's GC behavior.
JRockit garbage collection algorithms
JRockit uses mark-sweep-compact (MSC) as its base garbage collection algorithm, though it allows a lot of tweaking. The JVM command line option -Xgc: allows to choose variations of MSC algorithm. The following variations are available in JRockit R28:
| -Xgc: option | Generational | Mark | Sweep |
| genconcon or gencon | concurrent | concurrent | |
| singleconcon or singlecon | concurrent | concurrent | |
| genconpar | concurrent | parallel | |
| singleconpar | concurrent | parallel | |
| genparpar or genpar | parallel | parallel | |
| singleparpar or singlepar | parallel | parallel | |
| genparcon | parallel | concurrent | |
| singleparcon | parallel | concurrent |
There are also special values for -Xgc: (prior to R28 -XgcPrio: was used for this) options which instruct the JVM to use heuristics to choose best algorithm in run-time (unlike HotSpot JRockit can switch algorithms while the JVM is running, though documentation says that R28 is likely to stick with one algorithm).
- -Xgc:throughput - best throughput,
- -Xgc:pausegen - minimal pauses,
- -Xgc:deterministic - minimal pauses, stable pause time.
Generational vs single space
In my previous article , I explained the idea behind generational garbage collection. The generational approach assumes that space is divided into young and old space, each of which are collected by different algorithms (young space employs copy collector, while old space more sophisticated mark-sweep-compact). Keeping young and old space separate, requires the JVM to implement some kind of barrier to track old-to-young references. In generational mode JRockit uses a card marking barrier similar to one in HotSpot's CMS and throughput collectors (HotSpot's G1 is the only mainstream collector using other type of barrier). Unlike HotSpot which is always using generational approach, JRockit can operate in single space mode. Single space mode means:
- no young collection pauses,
- no write barrier unless it is needed for old space collector,
- more frequent old collection pauses,
- orders of magnitude worse throughput compared to generational collector.
Parallel vs concurrent
Parallel collectors require stop-the-world pause for the whole duration of major collection phases (mark or sweep), but employ all available cores to compress pause time. Parallel collectors usually have better throughput, but they are not a good fit for pause critical applications. Concurrent collector tries to do most work concurrently (though it also does it in parallel on multi-core systems), stopping the application only for short duration. The concurrent collection algorithm in JRockit is fairly different from both HotSpot's concurrent collectors (CMS and G1). I will explain how it works in details later in this article.
A Few differences between JRockit and HotSpot
Heap geometry
The HotSpot JVM has fixed heap geometry, in particular young, tenured and permanent spaces have fixed address ranges during the JVM life time (though physical memory may be partially committed). On the contrary, JRockit has single heap space. If a generational collection algorithm is used, some part of this space will be used for nursery (young space), though nursery in JRockit is not necessary continuous. The same is true for keep space (equivalent of survivor space in HotSpot). Both nursery and keep space may drift in the heap during JRockit's JVM life time. JRockit has no analog of HotSpot's permanent space.
Aging of objects in young space
HotSpot keeps the exact age (in terms of survived collection) associated with each object in young space. Using this knowledge HotSpot can keep an object in young space through several collections, which is an effective way to fight medium-aged garbage without increasing young space (though increasing young space is usually better in terms of performance). JRockit does not keep objects age, so objects are always promoted on second collection (first collection will move object to keep area, and second to old space).
Thread local allocation blocks and pauses
Both HotSpot and JRockit use TLABs (thread local allocation blocks) for fast object allocation. TLABs are allocated in young space/nursery (in single space mode, JRockit allocates TLABs in old space). Threads allocate new objects in their TLABs, and when a TLAB gets full, the thread requests a new one from the memory manager.
In HotSpot, all TLABs are recycled during young space collection (which is usually triggered by particular thread requesting TLAB block). JRockit is different, failure to allocate a new TLAB will trigger young GC, but it is not guaranteed that GC will start immediately or that GC will free enough continuous memory for TLAB. In later cases, the thread will be blocked waiting for TLAB while the JVM technically is not in stop-the-world pause. In other words, JRockit has two types of application pauses: stop-the-world pauses and TLAB wait pauses (affecting individual threads). From an application point of view, thread pauses are as bad as stop-the-worlds ones. It is impossible to guarantee service of application if random threads are blocked. The JVM may not fairly report TLAB wait pauses, so it is possible that application will experience pauses not reported by GC logs.
Concerning TLAB sizes, HotSpot is more aggressive for growing TLABs compared to JRockit. JRockit is more conservative because TLABs may survive several young collections. HotSpot recycles all TLABs in each young collection, so large TLABs are not going to be wasted if the thread would stop actively allocating objects.
JRockit's concurrent collector
JRockit has a very sophisticated concurrent collector. It is a variation of mark-sweep-compact algorithm. During mark phase, collector is traversing object graph marking all reachable objects. During sweep phase, whole heap is scanned and space from non-marked objects is reclaimed. Compact phase relocate objects in heap, fighting with fragmentation. JRockit can execute mark and sweep phases in concurrent mode. Concurrent implementation of mark phase requires breaking it into 3 sub phases:
- initial mark - stop-the-world pause to collect root references,
- concurrent marking - traversing graph without blocking application,
- remark - stop-the-world pause needed to account changes made by application during concurrent phase. During remark collector only have to revisit references changed since initial mark (card marking write barrier allow to do it efficently).
Concurrent marking is fairly straight forward. Sweeping also can be done concurrently with application (JRockit is using two short stop-the-world pause for sweeping, while HotSpot's sweep phase is fully concurrent). But if we just mark unused objects as free space it would eventually lead to fragmentation of heap and inability to allocate objects of moderate size, even if free space is available (death by fragmentation). JRockit is using compaction to protect itself against fragmentation.
Compaction is a very expensive operation. The JVM should move not only the object itself, it should also update all references to every relocated object. Compaction also requires stop-the-world pause and is single threaded in JRockit JVM. To avoid long compaction pauses, the garbage collector can do compaction incrementally. Each time when concurrent collection is stated, the JVM selects a range of heap space to be compacted. During the mark phase all references to objects in compaction area are collected. During the sweep phase, unreachable objects are marked as free space. And finally during the compact phase objects in compaction area are relocated. Compaction can be either internal (objects are relocated inside of compaction region), or external (objects are copied out to another region and whole old region becomes a free space). Compaction phase is abortable, JVM may choose to abort compaction half way if it is taking too much time. JVM may also decide not to move some objects if they have too many external references (or if they are pinned).
Even done incrementally compaction is significantly increasing pause duration. It is possible to turn off compaction altogether, but this way fragmentation becomes serious treat (unlike HotSpot's CMS, JRockit is not using free lists and statistical analysis to control fragmentation of heap).
JRockit's gencon vs HotSpot's CMS quick summary
Both use 4 phase concurrent marking (initial mark, concurrent sweep, concurrent preclean, remark). HotSpot's CMS is using fully concurrent sweep (without compaction).
JRockit may use compaction, compaction requires additional pause.
In JRockit initial mark and remark are forcing young collection. In HotSpot it is more flexible. Initial mark may wait for next young GC, while remark either force it or scan objects in Eden without young GC.
HotSpot's CMS is using free lists and statistical analysis to avoid fatal heap fragmentation. JRockit can do compaction, but very prone to fragmentation if compaction is not frequent enough.
Configuring JRockit for low pause on large heap
Garbage collection tuning is very application specific. So everything below has been written with certain type of applications in mind. Application class I'm interested in is same as in previous article. Its key characteristics are:
- Heap is used to store data structures in memory.
- Heap size 10GiB and more.
- Request execution time is small (up to dozens of milliseconds).
- Transactions are short (up to hundreds of milliseconds). Transaction may include several requests.
- Data in memory is modified slowly (e.i. we do not modify whole 10GiB in heap within one seconds, though updating of 10MiB data in heap per second is ok).
- Amount of short lived garbage is fairly large ~100-200MiB sec (garbage produced by parsing encoding network protocol, etc).
We have to for gencon algorithm and tune it by hands.
Sizing young space
Default size of young space in JRockit is 10MiB multiplied by number of young collection threads (young collection is done in parallel). Usually this default size is too small and you would want to increase it to reduce young GC frequency (-Xns<size> JVM option will help you). Compared to HotSpot, JRockit young space collection pauses are considerably shorter.
Keeping compaction pauses under control
JVM can abort compaction if it is taking too long. This is effective way to ensure max pause guaranty. Unfortunately you cannot just say -XpauseTarget=50 and relax. JRockit forbids pause target below 200ms if GC type is not set to deterministic, but if you use -Xgc:deterministic, JVM will choose singlecon mode and you will enjoy 5-30 second pauses (dependent on heap size) due to lack of throughput. This is really sad.
Due to pause target is locked out from our use, we have to use other options. There are too ways how we can prohibit long compaction:
- limiting size of compaction area (using -XXcompation:percentage=n option),
- limiting number of references to be updated during compaction (using -XXcomaption: maxReferences=n).
Running on 32GiB heap, good, bad and ugly.
Now I would like to share my experience of running 32GiB Oracle Coherence node on JRockit. Though I have spent enough time with tuning of GC options, there is still a fair chance that I have missed something. So please take my opinion with a grain of salt.
Good, young GC pause times
Young GC pause time are much better than HotSpot's CMS. It is roughly on par with patched version of JDK7 (even slightly better). Young collections are most frequent ones, this is really good that JRockit can handle them so well.
Bad, throughput
It is just not enough. I believe it is a curse of any compacting collector (HotSpot's G1 included). Modern hardware is just not enough to do all work associated with object relocation fast enough. But lack of throughput may not necessary be a show stopper. While my tests are fairly write intensive, for many applications JRockit's generational collector throughput may be enough.
In terms of throughput HotSpot's CMS beats out all competitors (probably except Azul Zing, which is using some intimate access to hardware not possible for common JVMs like HotSpot or JRockit).
Bad, fragmentation
Surprise! Compacting collector is prone to fragmentation. Combination of low throughput and incremental compaction leads to a fragmentation. Increasing throughput probably would remedy this problem, but it is impossible without significant increase in pause duration. Another way to counter fragmentation is increasing heap size, but this approach also have obvious practical limitation.
Ugly, long pauses
If you are looking only at logs of JRockit's GC, you may be kept under the assumption that pauses are short and low throughput is the only issue. It is not true. Your application may experience pauses not reported by JVM. You can easily measure them in your application code, though. After spending some time investigating this problem, I came to conclusion that the concurrent preclean phase is hindering young collection.
Normally young collection starts immediately, if TLAB cannot be allocated. But if concurrent preclean is active at the same time, it seems that the young collection can be delayed (and this delay can be significant 0.5-2 seconds depending on preclean phase duration). During that time threads are blocked waiting for TLAB. TLABs are usually small enough, so you have a good chance that most worker threads of your application will be blocked waiting for TLAB allocation. This is as severe as normal stop-the-world pause except, JVM does not report anything.
Why is preclean is affecting young collection? It is a good question, one possible reason is that remark which is scheduled after preclean requires young collection anyway, and the JVM thinks that this way it can avoid 2 pauses. Or it may be young collection interferes with concurrent preclean somehow using sharing data structures, so the JVM decides to delay it. The reason is not clear for me, but the consequence is unpredictable long application pauses which cannot be controlled.
This behavior is a serious show stopper for using JRockit in pause sensitive applications.
Deterministic pauses myth
JRockit claims what it can guarantee deterministic short pauses (below 50ms). This claim is absolutely valid. Single space concurrent collector, fully controls duration of pauses, so it can provide this guarantee. The problem is extremely low throughput though. Throughput can be increased by throwing in more memory for the application. But it will probably require tens or even hundreds times memory overhead to provide throughput comparable to the generational collector.
Conclusion
JRockit is a nice product, it has a lot of advanced features and is a very mature JVM. But so far I'm not going to use it for response time sensitive applications. Still I believe JRockit has good potential. There may also be kinds applications which can benefit from JRockit's garbage collection algorithms better than typical data grid.
Anyway it is good to have fair competition in the JVM area. Good luck to both JRockit and HotSpot products!
See also
Some of my other articles about garbage collection.
]]>
瀹屾暣鐨凷un JDK JVM鍙傛暟鍙弬鑰冨畼鏂規枃绔?http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
]]>
鍘熸枃: http://www.tagtraum.com/gcviewer-vmflags.html
VMFlags
When it comes to garbage collector and memory flags VMs from different vendors differ somewhat. Most flags aren't even properly documented by the usage printout of the VM themselves. This page tries to shine some light on what garbage collection related flags there are and what they are good for. It covers several Sun and IBM JVMs
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 -XX:+PrintGCDetails 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
-XX:+PrintGCApplicationStoppedTime
Instructs the VM to print out the length of actual collection pauses.
This flag is useful when tuning concurrent collectors.
Example:
Total time for which application threads were stopped: 0.0468229 seconds
Supported by: 1.4, 1.5
-XX:+PrintGCApplicationConcurrentTime
Instructs the VM to print out the amount of time the applications runs between collection pauses.
This flag is useful when tuning concurrent collectors.
Example:
Application time: 0.5291524 seconds
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 1:3; in other words, the combined size of
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 1:6; in other words, each survivor space
will be one eighth of the young generation (not one seventh,
because there are two survivor spaces).
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
Use the parallel old generation collector. Certain phases of an old generation collection can be performed in parallel, speeding up an old generation collection.
This option automatically enables -XX:+UseParallelGC .
Supported by: 1.5.0.6
-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 is1/(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 seeingStackOverflowErrors.
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.
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. Also note that the semantics of some of these parameters are different when used with IBM's resettable JVM for the z/OS platform.
Printing Information about GC
Prints out information about garbage collections to standard out.
See -Xverbosegclog
Supported by: 1.3.1, 1.4.1, 1.4.2
-Xverbosegclog:<path to file><filename[,X,Y]>
Prints out information about garbage collections to a file. If the integers X and Y are specified, the output is redirected to X files each containing output from Y GC cycles.
See -verbose:gc
Supported by: 1.4.1, 1.4.2
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, 1.4.1, 1.4.2
Overall minimum heap size. You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xmx256m sets the minimum heap size to 256mb
Supported by: 1.3.1, 1.4.1, 1.4.2
Sets the initial size of the system heap. Classes in this heap exist for the lifetime of the JVM. The system heap is never subjected to garbage collection. The maximum size of the system heap is unbounded. You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xinitsh256m sets the minimum system heap size to 256mb
Supported by: 1.3.1, 1.4.1, 1.4.2
This is a floating point number between 0 and 1, which specifies the maximum percentage of free space in the heap. The default is 0.6, or 60%. When this value is set to 0, heap contraction is a constant activity. With a value of 1, the heap never contracts. You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xmaxf0.6 specifies that the heap will be contracted if more
then 60% of the heap are unused.
Supported by: 1.3.1, 1.4.1, 1.4.2
This is a floating point number between 0 and 1, which specifies the minimum percentage of free space in the heap. The default is 0.3, or 30%. The heap grows if the free space is below the specified amount. You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xminf0.3 specifies that the heap will be grown if less
then 30% of the heap are unused.
Supported by: 1.3.1, 1.4.1, 1.4.2
Choosing and Configuring a Collector
-Xgcpolicy:<optthruput|optavgpause|subpool>
Note that the subpool option was introduced in Version 1.4.1 Service Refresh 1 for AIX only.
Setting gcpolicy to optthruput disables concurrent mark. If you do not have pause time problems (as seen by erratic application response times or by analysis of the verbose GC output), you should get the best throughput with this option. optthruput is the default setting.
Setting gcpolicy to optavgpause enables concurrent mark with its default values. If you are having problems with erratic application response times that are caused by normal garbage collections, you can remove those problems at the cost of some throughput when running with theoptavgpause option.
Setting gcpolicy to subpool enables improved object allocation that aims to achieve better performance in allocating objects on the heap. This setting might provide additional throughput optimization because it can improve the efficiency of object allocation and reduce lock contention on large SMP systems. Concurrent mark is disabled when this policy is enabled.
Supported by: 1.3.1, 1.4.1, 1.4.2
Sets the total number of threads that are used for garbage collection. On a system with n processors, the default setting is n.
Supported by: 1.3.1, 1.4.1, 1.4.2
Compacts the heap every garbage collection cycle. The default is false (that is, the heap is not compacted). This is not recommended.
Supported by: 1.3.1, 1.4.1, 1.4.2
Never compact the heap. Default is false.
Supported by: 1.3.1, 1.4.1, 1.4.2
Disables class garbage collection.
Supported by: 1.3.1, 1.4.1, 1.4.2
Miscellaneous Settings
Sets maximum native stack size for any thread.
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, 1.4.1, 1.4.2
Sets maximum Java stack size for any thread.
You may use k, m and g for kilobyte, megabyte and gigabyte.
Example:
-Xoss128k sets the stack size to 128kb
Supported by: 1.3.1, 1.4.1, 1.4.2
Runs full compaction each time java.lang.System.gc() is called. Its default behavior with ajava.lang.System.gc() call is to perform a compaction only if an allocation failure triggered a garbage collection since the last java.lang.System.gc() call.
Supported by: 1.4.1, 1.4.2
Never runs compaction when java.lang.System.gc() is called. Its default behavior with ajava.lang.System.gc() call is to perform a compaction only if an allocation failure triggered a garbage collection since the last java.lang.System.gc() call.
Supported by: 1.4.1, 1.4.2
Converts Java application calls to java.lang.System.gc() into no-ops.
Supported by: 1.4.1, 1.4.2
]]>