Memory leaks in all Java processes

[qazmlp]

All the Java processes that we have give memory leaks in a long run.
We have already fixed all the memory leaks from our application code.
But, still, resident stack size keeps growing always and it never
reaches the steady state. What else I can check with?

Are there leaks reported in the following Java version?
guiUser@hfnsn162(*)[43]: java -version
java version "1.2.2"
Solaris VM (build Solaris_JDK_1.2.2_05a, native threads, sunwjit)

 

[Rich Teer]

But, still, resident stack size keeps growing always and it never
reaches the steady state. What else I can check with?

Constant growth isn't necessarily a sign of memory leakage.

Are there leaks reported in the following Java version?
guiUser@hfnsn162(*)[43]: java -version
java version "1.2.2"
Solaris VM (build Solaris_JDK_1.2.2_05a, native threads, sunwjit)

I don't know, but I'd recommend using the latest version of the
JVM, just in case.

--
Rich Teer, SCNA, SCSA . * * . * .* .
. * . .*
President, * . . /\ ( . . *
Rite Online Inc. . . / .\ . * .
.*. / * \ . .
. /* o \ .
Voice: +1 (250) 979-1638 * '''||''' .
URL: http://www.rite-online.net ******************

 

[Bent C Dalager]

All the Java processes that we have give memory leaks in a long run.
We have already fixed all the memory leaks from our application code.
But, still, resident stack size keeps growing always and it never
reaches the steady state. What else I can check with?

I assume you are not actually referring to the stack size, which would
rapidly give you an overflow exception if it keeps growing, but that
you are rather referring to the heap or even just process memory usage
as reported by your OS.

If it is indeed the case that the heap is constantly growing, then it
should eventually run out of memory and start throwing exceptions.

More likely, perhaps, is that you've got some thread going that keeps
creating temporary objects that will eventually get cleaned up. Swing
is one common culprit. This is not usually a big problem.

In any case, I would use a profiler to track this down. JProbe and
OptimizeIt are two commercial options.

Cheers
Bent D

 

[Alan Coopersmith]

(e-mail address removed) (qazmlp) writes in comp.unix.solaris:
|All the Java processes that we have give memory leaks in a long run.
|We have already fixed all the memory leaks from our application code.
|But, still, resident stack size keeps growing always and it never
|reaches the steady state. What else I can check with?

RSS is not stack size - it's the amount currently cached in RAM, and
can grow or shrink independent of memory allocation/deallocation as
pages get paged in or out depending on how often they are accessed.
It's not a good measure of memory leaks at all.

 

[Rich Teer]

(e-mail address removed) (qazmlp) writes in comp.unix.solaris:
|All the Java processes that we have give memory leaks in a long run.
|We have already fixed all the memory leaks from our application code.
|But, still, resident stack size keeps growing always and it never
|reaches the steady state. What else I can check with?

RSS is not stack size - it's the amount currently cached in RAM, and

Just to expand a bit (for the OP), RSS = Resident Set Size.
I.e., the amount of the process' VM that is resident in RAM.

--
Rich Teer, SCNA, SCSA . * * . * .* .
. * . .*
President, * . . /\ ( . . *
Rite Online Inc. . . / .\ . * .
.*. / * \ . .
. /* o \ .
Voice: +1 (250) 979-1638 * '''||''' .
URL: http://www.rite-online.net ******************

 

[Casper H.S. Dik]

Just to expand a bit (for the OP), RSS = Resident Set Size.
I.e., the amount of the process' VM that is resident in RAM.

And it's normal for it to grow in absence of memory pressure to
be near equal in size to "SZ".

Casper