HP-UX Programmer's Guide for Java 2

Table Of Contents
For usage information, such as how to change the default IP version for JDK 5.0, see
“IPv6 support (Internet Protocol version 6) - SDK 1.4.2.x and later (page 29). Additional
information is also available at Oracle Networking IPv6 User Guide for J2SDK/JRE 1.4.
GC log-rotation support in 5.0
Prior to JDK5.0.17, when using GC logging options (for example, -Xverbosegc or
-Xloggc), GC data is written to a single file of unlimited size. Starting with JDK 5.0.17,
the JVM supports generation of multiple GC log files and rotates through the specified
number of files. This allows for easier archiving of GC data and helps limit the amount
of disk space consumed by the GC log. Log rotation is also supported when using
zero-preparation Xverbosegc.
To enable log rotation, use the following option together with -Xverbosegc, -Xloggc,
or zero-preparation Xverbosegc:
-XX:GCLogLimits=M,N
M is a non-negative integer for the number of GC records per file. Each GC record
corresponds to a GC event. A value of 0 specifies an unlimited number of records per
file.
N is a non-negative integer for the maximum number of files. A value of 0 specifies an
unlimited number of files.
When using this option, both M and N are required. If this option is not specified, then
the default behavior is to write a single GC log file with unlimited size.
When rotation is in effect, a sequence number is appended to the the GC filename (0
through N-1). (Examples of file names are: filename.0, filename.1, and filename.2.) With
log rotation, when the specified maximum number of files (N) is reached, logging cycles
back to the first file in the sequence (filename.0), overwriting old GC data with new
data. If the maximum number of files (N) is never reached, then no log rotation occurs.
Examples:
Rotate between two log files, each with a maximum of 100,000 GC records:
-XX:GCLogLimits=100000,2
Maintain an unlimited number of smaller files, each with a maximum of 1,000 GC
records:
-XX:GCLogLimits=1000,0
ThreadDumpPath support in 5.0
By default, sending the Java process a SIGQUIT signal results in a thread dump being
written to stdout. Starting with the JDK 1.5.0.19 release, the -XX:ThreadDumpPath=
<path/filename>option can be used to specify the thread dump file name or a
directory where the thread dump is created.
Dynamically loaded libraries in 5.0
The dlopen() RTLD_GLOBAL flag makes symbols in the library it loads available to
libraries loaded later. Using the Java -XX:-DllLoadGlobal option disables use of
86 JDK/JRE 5.0.n Usage Notes