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
We recommend you make a short and a long run. You can compare the two runs in
HPjmeter, and view the residual objects. Generally the lingering objects will percolate
to the top of the residual objects histogram, especially if the difference in run duration
is large enough or the leak rate is very high. Then you can look for objects of this type
in the Reference Graph. Following the graph from a candidate leaked object back
towards the root, you can see how that object is referenced by the application.
To determine if the application is leaking in the C heap, this can be easily observed
with GlancePlus in the Process Memory Regions window. The C heap is shown as the
DATA region. If the DATA region is continuously growing even after an extended
period of time at the steady load state, it may be a C heap memory leak.
There are several possible causes for a C heap leak with a java application:
• Leak in user JNI native methods
• Leak caused by a backlog of unexecuted java finalizers which hold on to C memory
• Leak in JDK code itself
If you have native methods in your application, including Type 2 JDBC drivers from
third party vendors, you can use the HP gdb memory leak detection capability. This
functionality has been extensively used with the JDK itself and we find it very reliable.
Leaks caused by unexecuted finalizers can be tricky to detect. Many java classes that
use finalizers do so to free memory allocated in the C heap. Since execution of finalizers
is generally slower than creation of new objects, it is possible in some situations to fill
up the C heap with yet-to-be-finalized java-related memory allocations, which may
cause other parts of the application or JDK to fail. Finalizers are not executed
synchronously during garbage collections. You can measure the finalization with
-Xrunhprof:heap=dump then use the Reference Graph in HPjmeter to see what is
unfinalized.
If all else fails and you still see a leak, it is occasionally possible to discover a leak in
the JDK. You should contact your HP Response Center to report it.
Diagnosing memory leaks 73