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

Allocation Site Statistics Data
LocationJVM Flags SpecifiedAction
Standard out
-XX:+PrintAllocStatistics
No special action taken
JVM will create a file for you, file
name format is: java_<pid>.vgc
-XX:+PrintAllocStatistics'kill -21 <pid>'
Standard out
-XX:+PrintAllocStatistics
-Xverbosegc
'kill -21 <pid>'
Same location as -Xverbosegc
data file (mydata.vgc)
-XX:+PrintAllocStatistics
-Xverbosegc:file=mydata.vgc
'kill -21 <pid>'
Standard out
-Xverbosegc'kill -21 <pid>'
Same location as -Xverbosegc
data file (mydata.vgc)
-Xverbosegc:file=mydata.vgc'kill -21 <pid>'
Sending multiple SIGPROF signals to a running Java process produces multiple
allocation site statistics dumps and the JVM dumps the buffered data immediately after
the SIGPROF is received. Allocation site statistics counters inside the JVM are reset
after each SIGPROF induced the dump of the data. HPjmeter consolidates data from
multiple allocation site statistics dumps into one report that is presented in a new tab
in the -Xverbosegc data visualizer.
Allocation sites can originate from interpreted as well as compiled Java code, when
specifying -XX:+PrintAllocStatistics, and only allocations coming from
compiled code are reported. The Java Virtual Machine detects and compiles the
application’s (and JDK's) most active Java methods as early as possible. Though
reporting allocation sites originating from compiled code is only incomplete from a
comprehensive reporting point of view, it does always report the most active allocation
sites (the sites most likely to cause GC performance problems).
JDK 6.0.04 flags
JDK/JRE 6.0.04 contains the following new options.
-XX:+UseAltHashPolicy Enables an alternate internal hash function and can reduce
Hash Map resizing for some applications. This option is enabled/disabled similarly to
all –XX JVM options; to enable it, specify -XX:+UseAltHashPolicy on the Java
command line; to disable it, specify -XX:-UseAltHashPolicy on the Java command
line. By default, this option is disabled.
-DdfCacheSize=n Caches internal computations for formatting floating point numbers
where n is the size of the cache, which may provide a performance benefit in some
cases. To enable it, specify -DdfCacheSize=n, where n is the size of the cache. The
value of n must be greater than 1 for caching to take effect. Users must be careful not
to specify too large a value for this cache. The cache is a JVM internal data structure
which resides in the Java Heap, so specifying too large a cache value might result in
excessive Full GC activity, which could impact application performance. A cache value
of 200,000 for a maximum Java heap size of 3.5 GB in 32-bit mode is considered large.
78 JDK/JRE 6.0.n and 7.0.n Usage Notes