Skip to content


August 5, 2008

So it is confirmed that with jdk1.4.2 hpjmeter is not able to display the dump as the dump generated on exit when application is running on tomcat 4.X results in errors.

So best to get the dump before the application exits and the – data should be in format=b  ( i.e. binary format)

Then one can easily see the output graphically and determine the thread counts etc.

I tried looking into the other tools that are bundled along – like jstat and jstatd – but apparently

jstat displays GC frequency and details while others like jstatd required a policy file – but even after setting the policy details it continued to give the security exception.


Where the file mypolicy has the data

grant codebase "file:../lib/tools.jar" {



So, I have decided to stick to hprof with the following options

cpu=samples, thread=y, format=b

and then view the data using hpjmeter.


Generate the core dump using gcore <pid>

To analyze this using gdb, you’d need to have both the core file and the “java” executable (the exact version that produced the core). The command to do this would be something like:

gdb /opt/java<whatever>/bin/java ./core

After loading the core file, gdb may report the cause of the program’s termination  and details.

Also you can try using the commands:

prstat – L



Question is how does one analyse the date retrieved from pstack.

In JDK 1.5 we have a lot of admin utilities to monitor in production environment:

Jstack is one that has output similar to kill -sigquit.

glanceplus HP util has some details on the running process as well.

G to view process list and s to select a specific process

|   F    | Process Open Files
|   L    | Process System Calls
|   M   | Process Memory Regions
|   R    | Process Resources
|   W   | Process Wait States

And I – Thread Resource, J – Thread Wait list.

Right now exploring – to use gdb:

gdb -exec=/usr/bin/java  -core=coreFile.28852

That gives me an error. Couldn’t find general-purpose registers in core file.

Installing 1.4.2_08 now…..

On doing gdb /usr/bin/java -core=coreFile it gives me —> Reading symbols from /app/java1.5/jre/lib/i386/server/… (no debugging symbols found)…done.

So the right way to generate core for debugging with gdb is :

Update – May 09

Use visual VM open source, Eclipse Memory Analyzer that takes the dump file
and soap UI for load testing .

Some other ways for jdk 1.5/1.6

Visual VM:

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: