Java memory leak-using runhprof?

[Vlado]

Hello ,
We are running currently Weblogic 5.1 with jdk 1.3.1_01, Solaris 7
(non-Intel).
I am trying to investigate a java memory leak, which is reprodusable
after long running of the Weblogic server.
I tried using JProbe as a profiler, but then the speed goes down 10
times and I even can not think of reproducing the problem.Now I am
looking for test case and script,that can reproduce the leak faster.

I have questions about the integrated jdk possibilities for profiling.
In the official sun documentation for J2SE 2 (jdk 1.2.2), they
describe some of the new feautures and tools in Java 2.
I read the following:
(NOTE that I found this description only in docs for SOLARIS)
"Increased performance is largely due to the scalable architecture of
the JVM which has improved in bytecode execution, memory management
and thread synchronization performance as a result of the following
features:....
...A heap inspection tool
This diagnostic tool for interactively killed programs is accessible
from the SIGQUIT handler menu. It can be used to find memory leaks in
your programs. A memory leak occurs when a program inadvertently
retains objects, preventing the garbage collector from reclaiming the
memory. Heap inspection presents a per-class breakdown of the objects
in the heap, sorted by total amount of memory consumed. You can then
examine reference chains to selected objects to see what is keeping
them alive."

Do they speak here about the java -hprof (-runhprof) parameters ,that
you can use?? But then why I can find this description
in the Solaris section?
If yes, do you know ,if it can help me.What I need is information
about the existing objects in JVM (after several days working
Weblogic).I read that "-hprof", when generating in text mode,will
generate file,which after 2 days working of JVM will be extremely
large.Is this so?
Can you give me some ideas,how to proceed?
Thanks a lot
Vlado

 

[Robert Olofsson]

Vlado ([email protected]) wrote:
: We are running currently Weblogic 5.1 with jdk 1.3.1_01, Solaris 7
: (non-Intel).

Ok, please remember that the jdk/1.3.x all has problems with profilers
they may crash randomly.

: I tried using JProbe as a profiler, but then the speed goes down 10
: times

Hmm, why? are you forced to do method profiling when you run jprobe?
if not, then 10 times seems much.

: I read that "-hprof", when generating in text mode,will
: generate file,which after 2 days working of JVM will be extremely
: large.Is this so?

The file should only be big if you have a large number of objects.

Im not sure if you can send signals to hprof and/or the standard
jvm to make it perform a heap dump (there are some signals for
monitor dumps though, so I would not be surprised if you can get
a heap dump).

Anyway you can try my profiler, jmp, available at
http://www.khelekore.org/jmp

You can start your program with very little profiling and then
do a heap dump after you belive that you have triggered the leak.
JMP gives you a graphical interface to inspect object owners which
is what you want to do when looking for leaks...

Have fun
/robo

 

[Vlado]

Robo,thank you for the answer.
I will try with JPM.
In general I want to know ,if it is possible to see which objecs are
alive in JVM without using a standard profiler.
Even -Xrunhprof run only for heap dump,slows down dramatically the
performance of JVM.
Is there a possibility ,that you take memory dump of the JVM, (here I
do not mean java heap dump), but dump of the physical memory used by
JVM and then extracting from this dump the info for the alive objects
in JVM?
In theory it is maybe possible, but is it implemented by someone?
Or is there a profiler ,that has not so big impact on the performance
and only before JVM exits,takes the thread dump?I though -Xrunhprof
works like this,when used as heap profiler,but it dumps something the
whole time,not only at the end !!??

Regards
Vlado

 

[Robert Olofsson]

Vlado ([email protected]) wrote:
: In general I want to know ,if it is possible to see which objecs are
: alive in JVM without using a standard profiler.

Well, you want a standard profiler, but you dont want it to trace
method, objects and monitors when you run.

: Is there a possibility ,that you take memory dump of the JVM, (here I
: do not mean java heap dump), but dump of the physical memory used by
: JVM and then extracting from this dump the info for the alive objects
: in JVM?

I do not know of any such tool

: Or is there a profiler ,that has not so big impact on the performance
: and only before JVM exits,takes the thread dump?

JMP should work like that if you give it the correct switches,
I often run something like:

java -Xrunjmp:nomonitors,noobjects,nomethods,filter=my.package my.package.Program

This slows the down the execution only marginally...

/robo