Memory leaks in all Java processes

Discussion in 'Java' started by qazmlp, Jan 2, 2004.

  1. qazmlp

    qazmlp Guest

    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)
     
    qazmlp, Jan 2, 2004
    #1
    1. Advertising

  2. qazmlp

    Rich Teer Guest

    On Thu, 1 Jan 2004, qazmlp wrote:

    > 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 ******************
     
    Rich Teer, Jan 2, 2004
    #2
    1. Advertising

  3. In article <>,
    qazmlp <> wrote:
    >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
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
     
    Bent C Dalager, Jan 2, 2004
    #3
  4. (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.

    --
    ________________________________________________________________________
    Alan Coopersmith
    http://www.CSUA.Berkeley.EDU/~alanc/ aka:
    Working for, but definitely not speaking for, Sun Microsystems, Inc.
     
    Alan Coopersmith, Jan 2, 2004
    #4
  5. qazmlp

    Rich Teer Guest

    On Fri, 2 Jan 2004, Alan Coopersmith wrote:

    > (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 ******************
     
    Rich Teer, Jan 2, 2004
    #5
  6. Rich Teer <> writes:

    >On Fri, 2 Jan 2004, Alan Coopersmith wrote:


    >> (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.


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

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
     
    Casper H.S. Dik, Jan 2, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Novice
    Replies:
    28
    Views:
    5,224
    Jon Skeet
    Jul 22, 2003
  2. qazmlp
    Replies:
    3
    Views:
    681
    Robert Olofsson
    Jan 7, 2004
  3. johan
    Replies:
    2
    Views:
    2,086
    johan
    Mar 2, 2004
  4. Peter Michaux
    Replies:
    6
    Views:
    119
    dhtml
    Feb 19, 2008
  5. Replies:
    4
    Views:
    156
Loading...

Share This Page