HP-UX Programmer's Guide for Java 2
Table Of Contents
- Table of Contents
- 1 Introduction
- 2 HotSpot Technology Tools and Commands
- 3 Configuration for Java™ Support
- 4 Performance and Tuning
- 5 Measuring System Performance
- 6 Using Threads
- 7 Using Signals
- 8 Using Java™ 2 JNI on HP-UX
- 9 Expanding Memory
- Determine your requirements
- Memory layout under HP-UX 11.0 (PA-RISC only)
- Additional memory available under HP-UX 11i (PA-RISC only)
- Allocating physical memory and swap in the Java™ heap
- Useful key command-line options for allocating memory
- Application-dependent considerations using large heap size HP-UX 11i PA-RISC
- Expanding heap size in native applications on PA-RISC HP-UX 11.11 and later releases
- Expanding heap size in native applications on Integrity HP-UX 11.23 and later releases
- Expanding heap size in HP-UX PA-RISC
- Expanding heap size in HP-UX Integrity
- 10 Diagnosing Memory Leaks
- A JDK/JRE 6.0.n and 7.0.n Usage Notes
- Using Java 2 JNI on HP-UX
- Garbage collection
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Compatibility with previous releases
- Java Cryptography Extension (JCE) policy files
- Configuring the Java Runtime Plug-In
- CLASSPATH environment variable
- Java Web Start technology usage
- Upgrading from a previous Java Web Start version
- IPv6 support
- Allocation Site Statistics and Zero Preparation -Xverbosegc
- JDK 6.0.04 flags
- GC log-rotation support
- NUMA collector enhancements
- ThreadDumpPath support
- Garbage-First garbage collector (-XX:+UseG1GC)
- jmap, jinfo, and jstack tools included in JDK 6.0.03
- Additional Java Web Start documentation
- B JDK/JRE 5.0.n Usage Notes
- Using Java 2 JNI on HP-UX
- Garbage collectors: Parallel and Concurrent Mark Sweep
- Allocating physical memory and swap in the Java heap
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Closing a socket (PA-RISC only)
- Compatibility with previous releases
- Java Cryptography Extension (JCE) policy files
- Allocation Site Statistics and Zero Preparation -Xverbosegc
- IPv6 support on Java 5.0
- GC log-rotation support in 5.0
- ThreadDumpPath support in 5.0
- Dynamically loaded libraries in 5.0
- Performance improvement for String.intern()
- Configuring the Java Runtime Plug-In
- CLASSPATH environment variable
- Java Web Start technology usage
- C SDK/RTE 1.4.2.n Usage Notes
- Removing support for unwanted architectures in the JRE
- Support for dynamic thread local storage (TLS)
- Signal Chaining functionality
- Using Java 2 JNI on HP-UX
- HotSpot JVM options
- Garbage collectors: Parallel and Concurrent mark sweep
- Allocating physical memory and swap in the Java heap
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Closing a socket when accept or read is pending (PA-RISC) - new patch information!
- Compatibility with previous releases
- Runtime Plug-In usage and configuration
- GC log-rotation support
- ThreadDumpPath support
- D Additional Resources
- Index

kill -21 6754
kill -s sigprof 6754
Issuing a second SIGPROF signal to the running Java program prompts the JVM to
stop emitting the -Xverbosegc information. Similarly, issuing yet another SIGPROF
signal to the running process prompts the JVM to start issuing -Xverbosegc
information one more time.
Additionally, starting with this release, and only if you had started the Java application
with -XX:+PrintAllocStatistics, when zero preparation -Xverbosegc is
enabled as specified in the previous paragraph, the JVM also emits detailed allocation
site statistics.
If you start your application with -XX:+PrintAllocStatistics, and if you do not
specify -Xverbosegc, or send the running process a SIGPROF signal, then the JVM
will emit allocation site statistics to standard out when the application terminates. (That
is, when the Java process stops running.) If you do not want to wait for the application
to terminate, or if the application is designed to be long running (or does not terminate),
then you can obtain allocation site statistics by sending the running Java program a
SIGPROF as described above.
Unlike -Xverbosegc information emission in zero preparation mode, which is started
with a SIGPROF and stopped with a second SIGPROF, when
-XX:+PrintAllocStatistics is specified, allocation site statistics is emitted every
time the JVM receives a SIGPROF.
When -XX:+PrintAllocStatistics is specified along with -Xverbosegc,
allocation site statistics data are directed to the same output specified for HP
-Xverbosegc. If no output file is specified, allocation site statistics are directed to
standard out (to the terminal where the program was started from). When
-XX:+PrintAllocStatistics is specified alone (without -Xverbosegc on the
command line), allocation site statistics are directed to standard out (to the terminal).
When a SIGPROF signal is sent to a running Java process that was originally started
with -XX:+PrintAllocStatistics on the command line, the SIGPROF signal will
also enable -Xverbosegc data collection if -Xverbosegc was not specified on the
command line when the program was started, and the output of both -Xverbosegc
and allocation site statistics is directed to a file created for you by the JVM. The name
of the file created by the JVM has the following format: java_<pid>.vgc. Where
<pid> is the Java process id. The following table lists all possible permutations and
corresponding locations of emitted data for both allocation site statistics and zero
preparation -Xverbosegc.
Allocation Site Statistics Data
LocationJVM Flags SpecifiedAction
Standard out
-XX:+PrintAllocStatistics
-Xverbosegc
No special action taken
Same location as -Xverbosegc
data file (mydata.vgc)
-XX:+PrintAllocStatistics
-Xverbosegc:file=mydata.vgc
No special action taken
Allocation Site Statistics and Zero Preparation -Xverbosegc 77