java‎ > ‎

HP JVM Options

posted Jul 21, 2010, 7:46 PM by Kuwon Kang
»Previous topic: Introduction
»Next topic: HP-UX configuration for Java™ support
»Back to table of contents

Unless stated otherwise, the information in this Programmer's Guide applies to HP-UX PA-RISC and HP-UX Itanium® Processor Family systems.

HotSpot technology is the default mode. If you want to run your 1.2 or 1.3 application without the HotSpot technology, you will need to use the -classic option. The -classic mode options are covered in "Classic Technology Tools, Commands, and Environment Variables."

Versions 1.4 and 5.0 are not supported on the Classic VM.

The HP-UX SDK, for the Java™ 2 Platform includes all the standard Java™ tools and provides HP enhancements. The Sun Microsystems' tools pages and HP-Specific features are provided below.

Table of contents
»Java™ tools pages
»Setting the class path
»How classes are found
»Excluding methods from being compiled
»Closing a socket when accept or read is pending (PA-RISC)
»Standard and non-standard options
»FastSwing (version 1.3x only)
»Non-blocking I/O Poll API (SDK 1.3 and later)
»IPv6 support (Internet Protocol version 6) (SDK 1.4 and later)

Java™ tools pages

The links below will take you to Sun Microsystems' documentation for the tools in the Java™ 2 SDK. All of the following tools are supported in our Java™ 2 platform Standard Edition™ for HP-UX.

 »Basic tools (javac, java, javadoc, appletviewer, jar, jdb, javah, javap, extcheck)
 »Remote Method Invocation (RMI) tools (rmic, rmiregistry, rmid, serialver) Internationalization Tools (native2ascii)
 »Security tools (keytool, jarsigner, policytool, kinit, klist, ktab)
 »Java™ IDL and RMI-IIOP Tools (tnameserv, idlj, orbd (1.4 only), servertool)

Setting the class path

The class path is the path that the Java™ runtime environment searches for classes and other resource files.

For information on how to set the class search path (more commonly known by the shorter name, "class path") refer to Sun Microsystems' documentation at:http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/classpath.html

How classes are found

For documentation on how the Java™ launcher and javac and javadoc find classes, refer to Sun Microsystems' documentation at: http://java.sun.com/j2se/1.4.2/docs/tooldocs/findingclasses.html

Excluding methods from being compiled

To prevent the HotSpot runtime compiler from compiling certain methods, you can create a file called.hotspot_compiler and add the method to be excluded to the file.

For example, if you want to exclude java/lang/String.indexOf() from being compiled, you would add the following line to the .hotspot_compiler file:

exclude java/lang/String indexOf

By default, the HotSpot VM looks for .hotspot_compiler under the directory where libjvm.sl resides. In addition, it looks for a .hotspot_compiler file in the current directory where the JVM was started.

For example, if you are running the JVM on a PA2.0 server, narrow mode, and the JVM was started from a script called run.sh in the directory /app/myapp/bin, it first looks in the directory{JAVA_HOME}/jre/lib/PA_RISC2.0/server and then it looks for a .hotspot_compiler file in the/app/myapp/bin directory.

Another way to exclude a method is to specify the .hotspot_compiler file using the VM option 
-XX:CompileCommandFile=<list of .hotspot_compiler files separated by ":">

Example:-XX:CompileCommandFile=/tmp/foo/.hotspot_compiler_app_version_71:\ 
/tmp/foo2/hc81

If you specify the -XX:CompileCommandFile option it overrides the default behavior of the VM and the VM will NOT scan either the libjvm.sl directory or the current directory for a .hotspot_compiler file.

Closing a socket when accept or read is pending (PA-RISC)

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. The default behavior when close() is called on a socket which has an outstanding read call from another thread is for the close() to block until the read call completes. With the 
-XdoCloseWithReadPending option, the socket close() call closes the socket and, in the context of the thread with the pending read, a Socket Exception with the message "Socket closed" is thrown.

In some versions of the VM, changes were made to the mechanism by which a socket is closed, and in those versions you no longer need to use the -XdoCloseWithReadPending option to close the socketclose() call.

However HP-UX patches are necessary for some PA-RISC versions. Please refer to the table below that describes whether HP-UX patches are needed for your Java™ version and PA-RISC operating system, and whether the flag needs to be used.

For HP Integrity systems, no flag and no HP-UX patches are required.

Java™ SDK VersionArchitectureHP-UX VersionHP-UX Patches RequiredJVM Flags Required
5.0PA-RISC 2.011.11, 11.23NoneNone
1.4.2.00 & 1.4.2.01PA-RISC11.0 and 11.11None-XdoCloseWithReadPending
11.23NoneNone
1.4.2.02 through 1.4.2.05PA-RISC11.0 
11.11 
11.23
NoneNone
1.4.2.06 & 1.4.2.07PA-RISC11.0NoneNone
11.11PHKL_32457
PHKL_25840
PHKL_25842
PHNE_25644
PHNE_25084
None
11.23NoneNone
1.3.1.00 & 1.3.1.01PA-RISC11.00 
11.11
None-XdoCloseWithReadPending
11.23NoneNone
1.3.1.02PA-RISC11.00PHNE_26728
PHNE_27063
PHNE_27092
PHKL_25842 
PHKL_25995
None
1.3.1.04 through 1.3.1.07PA-RISC11.00 
11.11
None-XdoCloseWithReadPending
11.23NoneNone
1.3.1.08 through 1.3.1.13PA-RISC11.00PHNE_26771None
11.11PHNE_28089None
11.23NoneNone
1.3.1.14 & 1.3.1.15PA-RISC11.00NoneNone
1.3.1.1511.11
11.23

Standard and non-standard options

The HP-UX SDK for the Java™ 2 Platform tools install into either /opt/java1.2/bin/opt/java1.3/bin,/opt/java1.4/bin or /opt/java1.5/bin directory, depending which SDK release you are installing. The installation process will update your system PATH to include the appropriate directory to allow you to invoke Java™ applications.

To see the full list of java options, enter the command:

java -help

To see the full list of non-standard options, enter the command:

java -X

For more information on each option, run the following command:

java <name of option>:help

For example, to see more information on -Xrunhprof, run this command:

java -Xrunhprof:help

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.

See also Sun Microsystems' "Java™ HotSpot VM Options" athttp://java.sun.com/docs/hotspot/VMOptions.html.

»-classic (version 1.2.2 and 1.3)
»-d64 (SDK version 1.4 and later)
»-Dhpux.font and -Dhpux.font.dpi (version 1.2.2 and later)
»-Dhpux.im.disable (version 1.2.2 and later)
»-Dhpux.im.enable.awt (version 1.2.2 and later)
»-Dhp.swing.use FastSwing (version 1.3.1 only)
»-pa11 (version 1.2.2 and later) PA-RISC only
»-verbosegc
»-Xbatch
»-Xbootclasspath
»-XdoCloseWithReadPending
»-Xeprof (version 1.2.2.05 and later)
»-XheapInitialSizes
»-Xincgc
»-Xint
»-Xmn<size>
»-Xms<size>
»-Xmx<size>
»-Xnocatch
»-Xnoclassgc
»-Xoptgc
»-Xprep
»-Xprof
»-Xrs (version 1.3.1 and later)
»-Xrunhprof
»-Xshare:on, -Xshare:off, -Xshared:auto
»-Xss<size>
»-Xusealtsigs
»-Xverbosegc<options>
»-XX:+AggressiveHeap
»-XX:+AllowUserSignalHandlers
»-XX:CompileCommandFile
»-XX:+DisableExplicitGC
»-XX:+ForceMmapReserved
»-XX:+HeapDump
»-XX:+HeapDumpOnly
»-XX:+HeapDumpOnCtrlBreak
»-XX:+HeapDumpOnOutOfMemoryError
»Interaction of HeapDump options
»-XX:MainThreadStackSize=<value>
»-XX:MaxDirectMemorySize=<size>
»-XX:MaxNewSize=<size>
»-XX:MaxPermSize<size>
»-XX:PermSize<size>
»-XX:NewSize=<size>
»-XX:NewSizeThreadIncrease=<size>
»-XX:-NoHandoff (version 1.3 and later)
»-XX:PrefetchCopyIntervalInBytes=n
»-XX:PrefetchScanIntervalInBytes=n
»-XX:+PrefetchScavengeFieldsAhead=n
»-XX:+PrefetchMarkSweep
»-XX:SchedulerPriorityRange=SCHED*,base,top
»-XX:+ServerApp
»-XX:SurvivorRatio=<size>
»-XX:+UseCompilerSafepoints (version 1.3.1 PA-RISC and later)
»-XX:+UseOnStackReplacement (version 1.3.1 PA-RISC and later)
»-XX:+UseParallelGC (version 1.4 and later)
»-XX:+UseSIGUSR2
»-XX:+UseGetTimeOfDay

-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

»Supported -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>]]

 »For Java™ 1.2 and 1.3 -Xverbosegc:help detailed explanation
 »For Java™ 1.4.0, -Xverbosegc:help detailed explanation
 »For Java™ 1.4.1 and 1.4.2, -Xverbosegc:help detailed explanation
 »For Java™ 5.0, -Xverbosegc:help detailed explanation

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.

Features

FastSwing (version 1.3x only) 
FastSwing is an HP feature which provides significant performance improvement for Swing Applications on a Remote X-Server. In HP's SDK 1.4.x and later, the FastSwing option is ignored because the Java™ 1.4 performance enhancements provide out-of-the-box performance for both local and remote displays, equivalent to FastSwing.

To use this feature invoke java or appletviewer as follows:

/opt/java1.3/bin/java -Dhp.swing.useFastSwing=true MyApp 
or 
/opt/java1.3/bin/appletviewer -J-Dhp.swing.useFastSwing=true applet.html

Currently we recommend using this feature only for Remote displays as it has the following caveat:

Double-buffered Swing Components cannot perform Graphics2D operations with the FastSwing feature turned on. When doing so you will get the following exception:

java.lang.ClassCastException: sun.awt.motif.X11OffScreenImage at 
BezierAnimationPanel.run(BezierAnimationPanel.java:223) at 
java.lang.Thread.run(Unknown Source)

Non-blocking I/O Poll API (SDK 1.3 and 1.4, deprecated in 5.0) 
com.hp.io.Poll supports a general mechanism for reporting I/O conditions associated with a set of FileDescriptors and for waiting until one or more conditions becomes true. Specified conditions include the ability to read or write data without blocking, and error conditions. Use of com.hp.io.Polldramatically reduces the number of threads required to support large numbers of clients in large server-side Java™ applications.

IPv6 support (Internet Protocol version 6) - SDK 1.4.2.x and later

IPv6 is a set of Internet Protocol specifications designed to provide enhancements over the capabilities of the existing IPv4 service in terms of scalability, security, mobility, ease-of-configuration, and real-time traffic handling.

For more information about IPv6, see Sun Microsystems' Networking IPv6 User Guide for J2SDK/JRE 1.4 at http://java.sun.com/j2se/1.4/docs/guide/net/ipv6_guide/

HP-UX 11i v1 (11.11), 11i v2 (11.23), and 11i v3 (11.31) support dual protocol stacks IPv4 and IPv6. IPv6 is not currently supported on HP-UX 11.0 or 11.22 (11i v1.5). To support IPv6, HP-UX 11i v1 (11.11) requires HP-UX patches; HP-UX 11i v2 (11.23) and 11i v3 (11.31) do not. See the following table for IPv6 support information.

IPv6 Support in HP-UX Java Releases

HP-UX Java PlatformInstall HP-UX 11.11 Patches?Install HP-UX 11.23 Patches?Install HP-UX 11.31 Patches?Default Protocol StackUse of Properties File?
SDK 1.4.2.xYesNoNoIPv4No
JDK 5.0–5.0.14YesNoNoIPv4No
JDK 5.0.15 and laterYesNoNoIPv4Yes
JDK 6.0–6.0.02YesNoNoIPv4No
JDK 6.0.03 and laterYesNoNoIPv6Yes

For the availability of HP-UX patches required for IPv6 support on HP-UX 11.11, please see

»Patch Information
»TOUR Transition Patches for HP-UX 11i

Setting IPv4 or IPv6 Support

The default protocol stack (IPv4 or IPv6) is set through the java.net.preferIPv4Stack system property. However, if you want to change the system property, you can set IPv4 or IPv6 support on the Java command line as follows:

IPv4 support:

-Djava.net.preferIPv4Stack="true"

IPv6 support:

-Djava.net.preferIPv4Stack="false"

 

Beginning with the JDK 5.0.15 and JDK 6.0.03 releases, you can use the properties file: 

  {JAVA_HOME}/jre/lib/net.properties 

to set IPv4 support: 

  java.net.preferIPv4Stack=true 

or to set IPv6 support: 

  java.net.preferIPv4Stack=false

 

Comments