Java 2 SDK for Solaris Developer's Guide

Java HotSpot VM Options

This chapter provides information on the command-line options and environment variables that can affect the performance characteristics of the Java HotSpotTM Virtual Machine. Unless otherwise noted, all information in this document pertains to both the Java HotSpot Client VM and the Java HotSpot Server VM. Refer to for more information on garbage collection (GC), threading, and performance FAQs for the Java platform.

The chapter contains the following sections.

Categories of Java HotSpot VM Options

Standard options recognized by the Java HotSpot VM are described on the man page for the Java Application Launcher (the java utility) and in the online documentation at This chapter describes non-standard options recognized by the Java HotSpot VM:

Java HotSpot VM Equivalents of Exact VM Options

For additional information on issues related to the Java HotSpot VM, see the online documentation at

Prior to version 1.3.0, the production releases of the Java 2 SDK for the Solaris Operating Environment 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 in Java 2 SDK v 1.4.0 are given in the following table.

EVM Option 


Java HotSpot VM equivalent 


Instruction tracing 

None (obsolete option) 


Method tracing 

None (obsolete option) 


Maximum java stack size 

None (Java HotSpot VM doesn't have separate native and Java programming language stacks) 


Verify heap integrity 





-XX:+VerifyAfterScavenge (all debug only)


Maximum compiled code size 

-Xmaxjitcodesize (used to be -Xmaxjitcodesize=32m, now -Xmaxjitcodesize32m)


Configure the heap 

(See The -Xgenconfig Option below.)


Use optimizing JIT Compiler 



Use concurrent garbage collector (1.2.2_07+) 

None (not yet in 1.3, 1.4) 

The Java HotSpot VM currently recognizes the following -X options that were not supported by the Exact VM.




Use Train GC 


Do not use Train Garbage Collection (default) 


Max percentage o fhead free after GC to avoid shrinking (default 0.7) 


Min percentage of heap free after GC to avoid expansion (default 0.4) 


Interpreter only 


Bind user-level threads (default in 1.4, not in 1.3) 


Set the size of the young generation (1.4 only) 

The -Xgenconfig Option

The young generation in the Java HotSpot VM consists of an eden and two equally sized semi-spaces, whereas the young generation in EVM consists of two equally size semi-spaces (with no eden). A command such as -Xgenconfig:32m,64m,semispaces:128m,512m,markcompact states that there are two 64mb semispaces each starting at 32mb and expandable to 64mb, and an old generation which starts at 128mb and can expand to 512mb. This creates a heap which is 640mb in size (maximum). In the Java HotSpot VM the equivalent command would be: -Xms256m -Xmx640m -XX:NewSize=32m -XX:MaxNewSize=64m As you can see, the Java HotSpot VM sets the total size of the heap with -Xms/-Xmx and then carves out the young generation from that space, whereas when using -Xgenconfig you must specify each generation's size.

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 VM 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 

Java HotSpot VM Option 




jbe is the same as -Xoptimize in 1.2–based systems, jit is the default. Use -server to replace -Xoptimize (or jbe) in 1.2.



traces methods as they are compiled (debug only in 1.3, available in 1.4) 



Done automatically on both systems, force architecture using these flags (Sparc/debug only) 

Java HotSpot VM Equivalents to _JVM_ARGS Environment Variables

_JVM_ARGS Environment 

Java HotSpot VM Option 




This option forces all threads to be created as bound threads (default in 1.4, not in 1.3). 



Disable young generation resizing. To do this on the Java HotSpot VM, simply set the size of the young generation to a constant (in 1.4; in 1.3, use -XX:MaxNewSize=<size> -XX:MaxNewSize=<size>).


-verbose:gc and/or -XX:+PrintGCDetails

Turns on various forms of gc statistics gathering. 






Integer specifying maximum number of bytecode instructions in a method which gets inlined. 



Print message about inlined methods (debug only) 









(debug only) Interval in milliseconds between yields 




Additional Java HotSpot VM arguments

Numbers can include 'k' or 'K' for kilobytes, 'm' or 'M' for megabytes, 'g' or 'G' for gigabytes, and 't' or 'T' for terabytes (for example, 32k is the same as 32768). Turn on a boolean flag with -XX:+<option> and off with -XX:-<option>.

Flag and Default 



Do not complain if the application installs signal handlers 


Alternate signal stack size (in Kbytes) 


Bump the number of file descriptors to max 


Maximum percentage of heap free after GC to avoid shrinking 


Minimum percentage of heap free after GC to avoid expansion 


Reserved code cache size (in bytes) — maximum code cache size 


Bind user level threads to LWPs (default on in 1.4) 


Use LWP-based instead of thread based synchronization (default on in 1.4) 


Use native thread priorities 


Size of the permanent genration. 


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(). VM still performs garbage collection when necessary.


On Solaris 9, this option is not necessary. On Solaris 8, J2SETM versions 1.3.1_02+ and 1.4+ require this option when using the alternate threads library. This option is not possible on pre-Solaris 8 operating environments.

For more information on threads libraries, see the threads document at

Those flags differing per architecture/OS. "Flag and Default" has the default of Sparc/-server.

Flag and Default 



Number of method invocations/branches before compiling [10,000 —server, 1,000 — client on Sparc, 1,500 on client x86] 


Maximum size of new generation (in bytes) [32m Sparc, 2.5m x86 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+); x86: 12] 


Default size of new generation (in bytes) [Sparc 2.125M, x86: 640k] 


Ratio of eden/survivor space size [Solaris: 64] 


Thread Stack Size (in Kbytes) (0 means use default stack size [Solaris Sparc 32–bit: 512, Solaris Sparc 64–bit: 1024, Solaris x86: 256]) 

-XX:+UseTLAB (XX:+UseTLE in J2SE 1.3)

Use thread-local object allocation [Sparc -server: true, all others: false] 


See Intimate Shared Memory, online at