HP-UX Programmer's Guide for Java 2

Currently, the first two cases require a command line like the following:
java -Xdebug -Xnoagent
-Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=y-classpath
class-path class-name
The -Xdebug option enables debugging. The -Xnoagent option disables the default
sun.tools.debug debug Agent. The -Djava.compiler=NONE option disables the
JIT compiler.
For the third case, you must use the same command-line options as described above,
but you are free to use your own mechanism for loading the JVMDI client into the
application VM. You do not need to use -Xrun.
The Connection and Invocation Details document at http://download.oracle.com/javase/
1.4.2/docs/guide/jpda/conninv.html or http://download.oracle.com/javase/1.5.0/docs/
guide/jpda/conninv.html contains more information on necessary VM invocation
options and sub-options of -Xrunjdwp.
For more information on JPDA, see Java Platform Debugger Architecture.
Diagnosing memory leaks
Java™ applications may be susceptible to two kinds of memory leaks, those in the
Java™ heap or in the C heap. If you see a java.lang.OutOfMemoryError, the
exception text may be helpful in determining what is happening, but not always. You
may find it helpful to read about the java memory layout to get an overall understanding
of application memory.
First of all, let your application run long enough to get to a steady state under a
representative workload. With the HotSpot JVM, it often takes about 10 minutes under
load for the runtime to get warmed up for maximum performance, so you should wait
at least this long before measuring anything. To determine if the leak is in the Java™
heap, first run your application with the extra option:
-Xverbosegc:file=<name>
This writes garbage collection and heap size statistics to the file. View this file and if
you find the the old space continuously grows, you can suspect a Java™ heap leak.
Next run the application with:
-classic -Xrunhprof:heap=dump
You must use a heap size of around 256 to 384MB in order for the dump to be written
correctly, but the data is perfectly valid and the information applies equally to running
under HotSpot. The algorithm for the heap dump requires it to mmap() a new region
almost as big as the heap itself to process the data. The classic JVM only can support
1GB of total writable data, so you have to keep the heap small enough to fit two of
them in there, and leave some extra space for the C heap.
When you exit the process gracefully at the end of the run, the heap contents are written
to the file java.hprof.txt. You can view this file with HPjmeter.
72 Diagnosing Memory Leaks