The HotSpot technology accepts all of the standard options as well as the following partial list of non-standard -X and -XX options. Non-standard options are not guaranteed to be supported on all VMimplementations, and are subject to change without notice in subsequent releases of the Java™ 2 SDK.
-classic (version 1.2.2 and 1.3)
Use the -classic command line option to run your application without the HotSpot technology. If you use the -classic option, it must be the first option in the java command line. The -classic mode options are covered in "Classic Technology Tools, Commands, and Environment Variables." The Classic VM is not supported on SDK 1.4 and JDK 5.0.
-d64 (SDK version 1.4 and later)
Runs Java™ in 64-bit mode. In HP SDK 1.4, interpreter and compiler -Xint, -Xmixed, and -Xcompmodes are supported.
-Dhpux.font and -Dhpux.font.dpi (version 1.2.2 and later)
To change the system font size of your Java™ application when it is launched, invoke Java™ with the command line option -Dhpux.font.dpi=[75|100] or -Dhpux.font=small_fonts.
-Dhpux.im.disable (version 1.2.2 and later)
This Java™ command line option is a workaround to allow Menu Mnemonics to work. It turns off the input method.
-Dhpux.im.enable.awt (version 1.2.2 and later)
This option is a workaround to allow the java input method to work with European locale composed characters. Using this option will disable the java input method for the Asian locale.
-Dhp.swing.use FastSwing(version 1.3.1 only)
This option improves the performance of swing APIs for Java™ for HP-UX version 1.3.1.
-pa11 (version 1.2.2 and later on PA-RISC only)
Note: If you run HotSpot with the -pa11 flag or run on a PA 1.1 system, your heap address space will be restricted to 1G.
PA1.1 binaries can be run on PA1.1 as well as PA2.0 systems; however, The PA2.0 shared libraries are the default if you are running on a PA2.0 system. You can override the use of the PA2.0 shared libraries on a PA2.0 system by specifying the -pa11 flag.
On a PA2.0 based system, if you invoke Java™ as follows, the default PA2.0 shared libraries are used.
java -version
If you invoke Java™ with the -pa11 option as follows, the PA1.1 shared libraries are used.
java -pa11 -version
-verbosegc
Prints out the result of a garbage collection to the stdout stream. At every garbage collection, the following 5 fields are printed:
[%T %B->%A(%C), %D]
%T is "GC:" when the garbage collection is a scavenge, and "Full GC:" when its a full garbage collection. A scavenge collects live objects from the New Generation only, whereas a full garbage collection collects objects from all spaces in the Java™ heap.
%B is the size of Java™ heap used before garbage collection, in KB.
%A is the size after garbage collection, in KB.
%C is the current capacity of the entire Java™ heap, in KB.
%D is the duration of the collection in seconds.
-Xbatch
(Excerpt below from Sun Microsystems' documentation.)
Disable background compilation. Normally, if compilation of a method is taking a long time, the VM will compile the method as a background task, running the method in interpreter mode until the background compilation is finished. The -Xbatch flag disables background compilation so that compilation of all methods proceeds as a foreground task until completed, regardless of how long the compilation takes. This flag is provided for users who desire more deterministic behavior of method compilation for purposes such as benchmarking.
-Xbootclasspath
Specify a semicolon-separated list of directories, JAR archives, and ZIP archives to search for boot class files. These will be used in place of the default boot class files in the jre/lib/rt.jar andjre/lib/i18n.jar archives normally used by the Java™ 2 software.
-XdoCloseWithReadPending
The java command line option -XdoCloseWithReadPending allows one thread to close() a socket when there is an outstanding read pending on that same socket from another thread.
For more informaton on when and how to use this option, refer to "Closing a socket when accept or read is pending" in this chapter.
-Xeprof
The -Xeprof option generates profile data for HPjmeter. The -Xeprof option controls profiling of Java™ applications running on JRE for HP-UX for the Java™ 2 Platform and collects method clock and CPU times, method call count, and call graph. (For more information on HPjmeter, see HPjmeter Downloads and Documentation.)
Note: Zero preparation profiling is a beta feature of the HP JDK/JRE 5.0.03. It is started from the command line by sending a signal to the JVM to start eprof. Engaging zero preparation profiling may have a short term impact on application performance as the JVM adjusts to the demands of performing dynamic measurements.
To profile your application use the following command:
java -Xeprof:<options> ApplicationClassName
To profile your applet, use:
appletviewer -J-Xeprof:<options> URL
where <options> is a list of <key>[=<value>] arguments separated by commas.
We have found the following options useful in most cases:
For CPU time metrics with minimal intrusion:
-Xeprof
Exact call count information and object creation profiling:
-Xeprof:inlining=disable
To see the complete list of available options, use
java -Xeprof:help
After the profiled applet or application terminates execution, the Java™ Virtual Machine writes the profile data to a file in the current directory. Use HPjmeter to analyze the file.
For more information on -Xeprof and supported -Xeprof options see -Xeprof Options
-XheapInitialSizes
Use the -XheapInitialSizes option to see the default value for the Java™ Heap.
-Xincgc
(excerpt from http://java.sun.com/products/hotspot/2.0/README.html)
Enables the incremental garbage collector. The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution. However, it can lead to a roughly 10% decrease in overall performance. -Xincgc 32-bit PA support is not available on SDK 1.4.0.x. 32-bit PA support for -Xincgc is available beginning with SDK 1.4.1.00.
-Xint
The HP-UX HotSpot compiler automatically and efficiently converts bytecode to native machine instructions at runtime. Only use the java -Xint option to disable the HotSpot compiler, if compiled code is not executing correctly and you have verified the problem with the HP Response Center. Disabled, the Java™ Virtual Machine interprets all Java™ methods.
-Xmn<size>
Sets the Java™ new generation heap size. The "new generation" is the first generation in HotSpot's generational garbage collector. (This option replaces the option -XX:NewSize=N.)
| Example: | | -Xmn64m |
| Default: | | In 1.3.1, the new size is 1/3 of ms, that is the initial or "starting" heap size. |
-Xms<size>
(excerpt from http://java.sun.com/products/hotspot/1.0/README.html)
Specifies the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. Do not use this option in conjunction with the -XX:+AggressiveHeap option. Doing so will cause the options to override each other's settings for heap size.
| Examples: | | -Xms6291456
-Xms6144k
-Xms6m |
|
| Default: | | -Xms2m |
-Xmx<size>
(excerpt from http://java.sun.com/products/hotspot/1.0/README.html)
Specifies the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. Do not use this option in conjunction with the -XX:+AggressiveHeap option. Doing so will cause the options to override each other's settings for heap size.
| Examples: | | -Xmx83886080
-Xmx81920k
-Xmx80m |
|
| Default: | | -Xmx64m |
-Xnocatch
The -Xnocatch option disables the Java™ "catch-all" signal handler. Use this option to generate clean stack traces from native code.
-Xnoclassgc
Disables class garbage collection.
-Xoptgc
The optimistic garbage collection flag. Improves garbage collection performance of applications with mostly short-lived objects. A server-side application that creates many short-lived objects for each transaction is likely to benefit greatly with Xoptgc. However this flag should be used with caution. It is not recommended for applications that build up objects quickly during the run time that are not short-lived.
-Xprep
The -Xprep option is used to dynamically preprocess (modify) bytecodes of the classes loaded by the VM. Its syntax is:
-Xprep <factory_class_name>:<arguments>
where <factory_class_name> is a qualified name of the class that will be used to create the preprocessor, and <arguments> is any string that will be passed to the method creating the preprocessor. The location of the factory class must be specified in the -Xbootclasspath option passed to the VM, together with the location of the appropriate rt.jar.
When the -Xprep option is specified, before loading the application classes, the Java™ VM will load the specified factory class and execute the method in the class declared as:
class <factory_class_name>
implements
Preprocessor {public static Preprocessor createPreprocessor (String arg)
where Preprocessor is an interface defined as:
package hp.javatools.bytecode;
public interface Preprocessor {public abstract byte[] instrument\
(String name, byte[] klass);}
The VM will pass the <arguments> specified in the -Xprep option to the createPreprocessor method as its only argument. The Preprocessor object returned by the invocation will be saved by the VM.
For each subsequently loaded class, the VM will invoke the instrument() method on the Preprocessor object, passing the name of the class being loaded, and the bytecode representation of the class. The returned array of bytes will be used by the VM as the replacement of the original version of the class. If null is returned, the original version of the class will be used.
-Xprof
(excerpt below from http://java.sun.com/products/hotspot/1.0/README.html)
Profiles the running program, and sends profiling data to standard output. This option is provided as a utility that is useful in program development and is not intended to be be used in production systems.
-Xrs (version 1.3.1 and later)
Reduces use of operating-system signals by the Java™ virtual machine (JVM), allowing for orderly shutdown of a Java™ application. Using the -Xrs option removes the signal handlers (for SIGHUP, SIGINT and SIGTERM) that run the shutdown hooks that are used to shut the application down in an orderly fashion. If you use -Xrs, the shutdown hooks won't be run if the application terminates as a result of receiving a SIGHUP, SIGINT or SIGTERM signal, unless the your code explicitly catches these and runs the shutdown hooks itself.
-Xshare:on, -Xshare:off, -Xshared:auto
UserSharedSpaces is not supported on HP-UX
-Xrunhprof
Enables cpu, heap, or monitor profiling. This option is typically followed by a list of comma-separated "<suboption>=<value>" pairs. Run the command java -Xrunhprof:help to obtain a list of suboptions and their default values.
-Xss<size>
(excerpt below from http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html#options)
Set the maximum native stack size, in bytes, for any thread. Each Java™ thread has two stacks: one for Java™ code and one for C code. This option sets the maximum stack size that can be used by C code in a thread. Every thread spawned during the execution of the program passed to java will have the number you specify in this option as its C stack size. This flag is appropriate for programs that have small thread stack size requirements and/or create several thousand threads, with the potential for running out of virtual memory. Append the letter k or K to indicate kbytes, and m or M for megabytes.<size> must be > 1000 bytes.
| Defaults: | | -Xss512k (Java™ 1.3, 1.4, and 5.0 32-bit mode) |
| | | -Xss1m (Java™ 1.4 and 5.0 64-bit mode) |
Note: The default stack size for 1.4 and 5.0 64-bit mode JVM - created threads is 1MB. On PA-RISC 32 and 64-bit systems, the default stack size is 64 KB. Therefore, if you are using C language main programs that attach with JNI, you will want to adjust the stack size to avoid overflows.
-Xusealtsigs (replaces -XX:+UseSIGUSR2 beginning with SDK 1.3.1.13, 1.4.1 and 1.4.2)
Instructs the JVM to avoid using SIGUSR1 and SIGUSR2 for internal operations (like Thread.interrupt()calls). In SDK 1.4.1 and later, by default the JVM uses both SIGUSR1 and SIGUSR2. In SDK 1.3.1.13 onlySIGUSR1 is used. If -Xusealtsigs is used, then two signals halfway between SIGRTMIN and SIGRTMAX will be chosen instead.
-Xverbosegc<options>
The -Xverbosegc option prints out detailed information about the spaces within the Java™ Heap before and after garbage collection.
Beginning with 1.3.1.14 and 1.4.2.05, the process id will be automatically appended to the verbosegcfilename you specify. This helps you to associate a verbosegc output with the corresponding Java™ process, especially in cases where an application executes several Java™ processes.
The syntax of the option is:
-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]
In addition we recommend HP's garbage collection analysis tool HPjtune, which displays information contained in an Xverbosegc log graphically. HPjtune is available at no cost from Java™ Technology Software on HP-UX
For documentation on the new garbage collectors, refer to "Tuning Garbage Collection with the 1.4.2 Java™ Virtual Machine" at http://java.sun.com/docs/hotspot/gc1.4.2/index.html
-XX:+AggressiveHeap
(excerpt from http://java.sun.com/docs/hotspot/ism.html)
This option instructs the JVM to push memory use to the limit. It sets the overall heap to around 3850MB, the memory management policy defers collection as long as possible, and (beginning with J2SE 1.3.1.05) some GC activity is done in parallel. Because this option sets heap size, do not use the-Xms or -Xmx options in conjunction with -XX:+AggressiveHeap. Doing so will cause the options to override each other's settings for heap size.
Because the -XX:+AggressiveHeap option has specific system requirements for correct operation and may require privileged access to system configuration parameters, it should be used with caution. We have found it to be useful for certain applications that create a lot of short lived objects.
-XX:+AllowUserSignalHandlers
Instructs the HotSpot JVM not to complain if the native code libraries install signal handlers. This only matters if the handlers were installed when the VM is booting.
-XX:CompileCommandFile=<list of .hotspot_compiler files separated by ":"> (version 1.3.1.10, 1.4.1.06, 1.4.2.00 and later)
Specifies one or more .hotspot_compiler files that you do not want to be compiled by the JVM. Specifying this option overrides the default behavior of the JVM which is to scan the libjvm.sl directory or the current directory for a .hotspot_compiler file.
-XX:+DisableExplicitGC
Disable calls to System.gc(), JVM still performs garbage collection when necessary.
-XX:+ForceMmapReserved
Use this option to reserve the space for all large memory regions used by the JVM. This includes the Java™ Heap, which is an mmap'ed space. Starting with HP-UX 11.11, the default behavior is that the memory regions be reserved lazily. Most large server-side applications will use all of the space, so improved performance can be obtained by reserving the space at program initialization.
-XX:+HeapDump
The -XX:+HeapDump option can be used to observe memory allocation in a running Java™ application by taking snapshots of the heap over time. Using the _JAVA_HEAPDUMP=1 environment variable allows memory snapshots to be taken without modifying the java command line.
The HeapDump functionality is available starting with SDK 1.4.2.10 and JDK 1.5.0.03.
To enable this functionality, use the command-line option -XX:+HeapDump or set the environment variable _JAVA_HEAPDUMP=1 before starting the Java™ application. (e.g. export _JAVA_HEAPDUMP=1)
This output is similar to -Xrunhprof:heap=dump. The difference is that the thread info (THREAD START) and trace info (TRACE) will not printed to the output file.
With the option enabled, each time you send the process a SIGQUIT signal the JVM produces a dump of the Java™ heap (a Java™ heap snapshot), in hprof format. The name of the file will have the following format:
java_<pid>_<date>_<time>_heapDump.hprof.txt
By creating a series of these snapshots you can see how the number and size of objects varies over time.
Note: a full GC is executed prior to the Heap snapshot.
Please also note the section on ‘Interaction of HeapDump Options’.
-XX:+HeapDumpOnly and _JAVA_HEAPDUMP_ONLY
Beginning with SDK 1.4.2.11, the option -XX:+HeapDumpOnly can be used to enable HP Heap Dumps using SIGVTALARM signal (signal 20). To enable this feature without altering the java command line, the environment variable _JAVA_HEAPDUMP_ONLY can be set in the user's environment prior to executing the java application java.
If _JAVA_HEAPDUMP_ONLY is set, or -XX:+HeapDumpOnly command line option is used, then the HP HeapDump functionality will be triggered by sending signal SIGVTALRM (20) to the process, and the printing of thread and trace information to stdout is suppressed.
The HeapDump is written to a file with the following filename format:
java_<pid>_<date>_<time>_heapDump.hprof.txt
The default output format is ASCII. The output format can be changed to hprof binary format by setting the _JAVA_BINARY_HEAPDUMP environment variable, which is used to specify that heap dumps be emitted in binary format only. By default the -XX:+HeapDump and -XX:+HeapDumpOnly options will emit heap dump information in ascii format.
Please note the section on ‘Interaction of HeapDump Options’.
-XX:+HeapDumpOnCtrlBreak
The command line option -XX:+HeapDumpOnCtrlBreak enables the ability to take snapshots of the java heap when a SIGQUIT is sent to the java process, without using the jvmti-based -Xrunhprof:heap=dump.
This feature is similar to the -XX:+HeapDump option, except the output format is binary hprof format, and is placed into a filename with the following naming convention:
The HeapDump is written to a file with the following filename format:
java_<pid>_heapDump.hprof.<millitime>
The option -XX:+HeapDumpOnCtrlBreak is available starting with SDK 1.4.2.11 and JDK 5.0.05.
Please note the section on ‘Interaction of HeapDump Options’.
-XX:+HeapDumpOnOutOfMemoryError
The HeapDumpOnOutOfMemoryError command line option causes the JVM to dump a snapshot of the Java™ heap when an Out Of Memory error condition has been reached. The heap dump format generated by HeapDumpOnOutOfMemoryError is in hprof binary format, and is written to filenamejava_pid<pid>.hprof in the current working directory.
The option -XX:HeapDumpPath=<file> can be used to specify the dump filename or the directory where the dump file is created. Running with application with -XX:+HeapDumpOnOutOfMemoryError does not impact performance. Please note the following known issue: The HeapDumpOnOutOfMemoryError option does not work with the low-pause collector (-XX:+UseConcMarkSweepGC). This option is available starting with the SDK 1.4.2.11 and JDK 5.0.04 releases.
Interaction of HeapDump options
If the HP environment variable _JAVA_HEAPDUMP is set and the option -XX:+HeapDumpOnCtrl is specified, then both the HP ascii and JS hprof binary formats will be emitted when signal -3 is sent to the process:
java_pid27298.hprof.1152743593943
java_27298_060712_153313_heapDump.hprof.txt
If only the binary format heap dump is desired (
on SIGQUIT), then set only _JAVA_BINARY_HEAPDUMP environment variable, or use
-XX:+HeapDumpOnCtrl (without setting _JAVA_HEAPDUMP environment variable).If _JAVA_BINARY_HEAPDUMP is set and
-Xrunhprof:heap=dump is set, then both the runhprof ascii-based and HP binary files are produced.If _JAVA_HEAPDUMP_ONLY is set then the Heap Dumps are triggered via the SIGVTALRM signal (20), instead of SIGQUIT (3); then only the heapdump is produced (thread and trace dump to stdout of app is supressed);_JAVA_HEAPDUMP_ONLY and _JAVA_BINARY_HEAPDUMP will produce a binary format heap dump when SIGVTALRM is sent to the process. No thread trace is generated to stdout.
-XX:MainThreadStackSize=<value>
Specifies the main/primordial thread stack size. The main/primordial thread is the first thread when a process is created. It is the thread that has the main method. Other Java™ threads are controlled by -Xss<size>. See also "Using JNI - main/primordial thread stack size limits."
-XX:MaxDirectMemorySize=<size>
Specifies the maximum amount of memory in bytes that the Java™ NIO library can allocate for direct memory buffers. The default is 64 megabytes, which corresponds to
-XX:MaxDirectMemorySize=64m. The use of direct memory buffers can minimize the copying cost when doing I/O operations.
-XX:MaxNewSize=<size>
Sets the maximum size of new generation (in bytes). The arguments can now be followed by either 'k' or 'm' to specify KB or MB. For 1.2, specify KB only. Not supported in 1.3.
-XX:MaxPermSize=<size>
Sets the maximum size of permanent generation (in bytes). Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. For example, -XX:MaxPermSize=32m specifies a value of 32MBytes for MaxPermSize (Note that in SDK 1.2.2, this option took an integer that specified a value in kbytes only).
Default: 64MB
-XX:PermSize=<size>
Specifies the initial size, in bytes, of the Permanent Space memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes.
| Examples: | | -XX:PermSize=6291456
-XX:PermSize=6144k
-XX:PermSize=6m |
|
| Default: | | -XX:PermSize=16m (1.4 and later) |
-XX:NewSize=<size>
Sets the default size, in bytes, of new generation. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. (For 1.2, specify KB only). Not supported in 1.3.
-XX:NewSizeThreadIncrease=<size>
Sets the additional size, in bytes, added to desired new generation size per non-daemon thread. (Note that in SDK 1.2.2, this option took an integer that specified a value in kbytes only).
-XX:-NoHandoff (version 1.3 and later)
XX:-NoHandoff works in conjunction with the new functionality added in HP-UX 11.11 HP-UX patch PHCO_25226. In HP-UX 11.22 and later, this option has less impact than for HP-UX 11.11.
-XX:PrefetchCopyIntervalInBytes=n
Prefetch n bytes ahead for scavenge copy destination area. The default is 0. The ideal value may vary depending on the processor.
-XX:PrefetchScanIntervalInBytes=n
Prefetch n bytes ahead for scavenge scan area. The default is 0. The ideal value may vary depending on the processor.
-XX:+PrefetchScavengeFieldsAhead=n
Prefetch the next n fields of objects during scavenge. The default is 0. The ideal value may vary depending on the processor.
-XX:+PrefetchMarkSweep
Use prefetching during full garbage collections. The default is true.
-XX:SchedulerPriorityRange=SCHED
This option can be used to both select the scheduling policy and map the Java™ thread priorities, 1 (low) through 10 (high), to the underlying HP-UX thread priorities:
SCHED* is one of the scheduling policies:
SCHED_FIFO
SCHED_RR
SCHED_RR2
SCHED_RTPRIO
SCHED_OTHER
SCHED_HPUX
SCHED_NOAGE (a subset of the range of priorities supported by CHED_TIMESHARE)
SCHED_TIMESHARE is not supported as an option, but is the same
as SCHED_HPUX and use of any such non-supported
SCHED* will result in using the default policy,
SCHED_HPUX.
base - the HP-UX minimum value for the set of priorities to be mapped
top - the HP-UX maximum value for the set of priorities to be mapped
The format can be:
-XX:SchedulerPriorityRange<scheduler>,<base>,<top>
or <scheduler>
or <scheduler>,<base>
or <scheduler>,,<top>
Normally, the underlying system interfaces allow you to obtain the max and
min priorities:
sched_get_priority_max()
sched_get_priority_min()
However, in Java, the range of priorities must be passed to the JVM at start-up.
Therefore, we need to know the values prior to starting the application.
For each of the scheduling policies:
POSIX PRIORITIES: SCHED_FIFO, SCHED_RR, SCHED_RR2
The POSIX priorities range from 0 to 31 where 31 is the highest and 0 is the
lowest. The number of priority levels can be changed with the kernel parameter
'rtsched_numpri'
(possible values are 32-512).
REALTIME PRIORITIES: SCHED_RTPRIO
The range is -128 to -1.
TIMESHARE PRIORITIES: SCHED_HPUX, SCHED_NOAGE
For SCHED_HPUX, the default range is -256 (base) to -129 (top).
-129 to -154 are system priorities available only to 'root' users
-179 to -256 are user timeshare priorities
For SCHED_NOAGE, the range is -256 (base) to -154 (top). For HP-UX 11.11 and
later releases, the highest value is -179 (top).
An example of the use of the option on HP-UX 11.11 and later HP-UX releases is:
-XX:SchedulerPriorityRange=SCHED_NOAGE,-199,-179
The SCHED_NOAGE scheduling policy will be used - a thread's priority will remain
fixed.
The Java™ thread priorities will map as:
1:
-199
2:
-197
3:
-195
4:
-193
5:
-191
6:
-189
7:
-187
6:
-185
8:
-183
9:
-181
10:
-179
-XX:+ServerApp
A set of XX options which may make long running server applications run faster. The XX options and their values, such as the tunable option for thread local sizes, are modified over time based on the application results we observe. For each release, the options as well as the values may be different depending upon the default values of XX options. We recommend that you test to see whether this set enhances the performance of your application before you use the option in production.
-XX:SurvivorRatio=<size>
Ratio of eden/survivor space size. The default is 8, meaning that eden is 8 times bigger than from and to, each. Here are some examples:
Xmn / (SurvivorRatio + 2) = size of from and to, each
( Xmn / (SurvivorRatio + 2) ) * SurvivorRatio = eden size
If your new generation heap is 100MB, the space reserved for objects to survive a garbage collection is1/2*(100MB/8), or 6.25MB. Raising this value may improve overall application performance when the New space is large and/or when your application keeps a very low percentage of objects.
-XX:+UseCompilerSafepoints (PA-RISC 1.3.1, 1.4 and later, Itanium 1.4.2 and later)
Enables compiler safe points. Enabling compiler safepoints guarantees a more deterministic delay to stop all running java threads before doing a safepoint operation, namely garbage collection and deoptimization. In HP SDK 1.3.1 and 1.4 releases, compiler safe points is off by default, and you may also require a HP-UX patch. Refer to the release notes for your SDK for more information.
-XX:+UseOnStackReplacement (PA-RISC 1.3.1, 1.4 and later, Itanium 1.4.2 and later)
Enables on stack replacement. On stack replacement enables the interpreter to go into compiled code while it is executing the same instance of the method call. For example, if the VM is executing a method that has a loop with a large number of iterations, an intra-method hotspot will occur. To get better performance, the method should run in compiled mode instead of interpreted mode. If you enable on stack replacement, you should also enable compiler safe points (see the previous option). In HP SDK 1.3.1 and 1.4 releases, on stack replacement is off by default, and you may also require a HP-UX patch. Refer to the release notes for your SDK for more information.
-XX:+UseParallelGC (version 1.4 and later)
Use parallel garbage collection. The parallel collector has been enhanced in 5.0 to monitor and adapt to the memory needs of the application in order to eliminate the need to tune command-line options to achieve the best performance. For a synopsis of garbage collection features, refer tohttp://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
-XX:+UseSIGUSR2 (for SDKs 1.4.0.x and 1.3.1.00 through 1.3.1.12)
Replaced by the -Xusealtsigs option.
Instructs the JVM to use SIGUSR2 for internal operations like Thread.interrupt() calls instead ofSIGUSR1, the default. This allows you to better implement third party middleware applications that in some versions want to use SIGUSR1 for similar purposes in their native code.
-XX:+UseGetTimeOfDay
Instructs the JVM to use the GetTimeOfDay call instead of the mechanism used in earlier versions whereby the number of cpu ticks since the application started is used to calculate the current time. With this new mechanism, changes to the system date or time using date(1), adjtime(2), or time synchronization utilities such as ntp are not reflected in the date and time that Java™ returns, until the process is restarted. If your application requires that Java™ immediately reflects such system time changes, you can use the -XX:+UseGetTimeOfDay option, however you may notice a drop in performance.
