Memory leak in Java app

Discussion in 'Java' started by Alan Morgan, Oct 25, 2007.

  1. Alan Morgan

    Alan Morgan Guest

    I have a Java app, running on Windows, with a medium amount
    of C++ wrapper code doing various arcane and boring things.
    JProfiler swears that there isn't a memory leak in the Java.
    Purify claims that there isn't a memory leak in the C++. According
    to ProcessExplorer, however, we leak memory (or rather, the
    Private Byte and Working Set keep rising). Some of this might
    be induced by memory fragmentation, I suppose, but other than
    that and the thought that Sun's JVM might leak memory (possible?),
    I'm not sure where to go.

    I'm currently using Sun's 1.5 JVM. Client and Server mode doesn't
    make much of a difference (the amount of memory used goes down,
    but the increase remains). I haven't tested extensively with 1.6,
    but saw essentially the same behavior with my quick look.

    Is futzing with the GC parameters going to accomplish anything?
    Is this just expected behavior? Is the only solution to kill and
    resume the app on a regular basis?

    Alan
    --
    Defendit numerus
    Alan Morgan, Oct 25, 2007
    #1
    1. Advertising

  2. Alan Morgan

    Daniel Pitts Guest

    Alan Morgan wrote:
    > I have a Java app, running on Windows, with a medium amount
    > of C++ wrapper code doing various arcane and boring things.
    > JProfiler swears that there isn't a memory leak in the Java.
    > Purify claims that there isn't a memory leak in the C++. According
    > to ProcessExplorer, however, we leak memory (or rather, the
    > Private Byte and Working Set keep rising). Some of this might
    > be induced by memory fragmentation, I suppose, but other than
    > that and the thought that Sun's JVM might leak memory (possible?),
    > I'm not sure where to go.
    >
    > I'm currently using Sun's 1.5 JVM. Client and Server mode doesn't
    > make much of a difference (the amount of memory used goes down,
    > but the increase remains). I haven't tested extensively with 1.6,
    > but saw essentially the same behavior with my quick look.
    >
    > Is futzing with the GC parameters going to accomplish anything?
    > Is this just expected behavior? Is the only solution to kill and
    > resume the app on a regular basis?
    >
    > Alan

    Only assume you're leaking memory if over a sufficient time period, you
    get OOM exceptions. Java is a Garbage Collected environment, which
    means that some objects may just hang around until the GC decides its
    time to clean them up. Looking at the java processes memory consumption
    doesn't tell you what is actually in use. The garbage collector usually
    doesn't try very hard until the used memory gets to be very close to
    "full" for the currently allocated heap size.

    In other words, its normal to have memory usage creep up slowly and
    then, with no warning or explanation, drop down to normal levels again.


    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Oct 25, 2007
    #2
    1. Advertising

  3. Alan Morgan

    Roedy Green Guest

    On Thu, 25 Oct 2007 14:06:03 -0700 (PDT),
    (Alan Morgan) wrote, quoted or indirectly quoted someone who said :

    >I have a Java app, running on Windows, with a medium amount
    >of C++ wrapper code doing various arcane and boring things.
    >JProfiler swears that there isn't a memory leak in the Java.
    >Purify claims that there isn't a memory leak in the C++


    but you may have some packratting. See
    http://mindprod.com/jgloss/packratting.html
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Oct 25, 2007
    #3
  4. Alan Morgan

    Alan Morgan Guest

    In article <>,
    Daniel Pitts <> wrote:
    >Alan Morgan wrote:
    >> I have a Java app, running on Windows, with a medium amount
    >> of C++ wrapper code doing various arcane and boring things.
    >> JProfiler swears that there isn't a memory leak in the Java.
    >> Purify claims that there isn't a memory leak in the C++. According
    >> to ProcessExplorer, however, we leak memory (or rather, the
    >> Private Byte and Working Set keep rising).

    >
    >Only assume you're leaking memory if over a sufficient time period, you
    >get OOM exceptions. Java is a Garbage Collected environment, which
    >means that some objects may just hang around until the GC decides its
    >time to clean them up. Looking at the java processes memory consumption
    >doesn't tell you what is actually in use. The garbage collector usually
    >doesn't try very hard until the used memory gets to be very close to
    >"full" for the currently allocated heap size.


    I'm aware of that, but there may be some subtlties in the Java GC that
    I'm missing. JProfiler claims that the heap never grows beyound about
    10MB. I see regular garbage collections occurring which generally reduce
    my consumption from about 9MB to about 6MB. I can run the system all day
    and this won't change. However, Process Explorer insists that my app,
    which started off using 30MB of private memory, is now using 60MB. Forcing
    a GC via JProfiler doesn't do anything to change this.

    Obviously using JProfiler is going change the system behavior and mess
    with these numbers blah blah Heisenberg. I realize this is not an exact
    science.

    Alan
    --
    Defendit numerus
    Alan Morgan, Oct 25, 2007
    #4
  5. Alan Morgan

    Mark Space Guest

    Alan Morgan wrote:

    > and this won't change. However, Process Explorer insists that my app,
    > which started off using 30MB of private memory, is now using 60MB. Forcing
    > a GC via JProfiler doesn't do anything to change this.
    >
    > Obviously using JProfiler is going change the system behavior and mess
    > with these numbers blah blah Heisenberg. I realize this is not an exact
    > science.


    Roedy's link explains that not calling dispose() on GUI objects results
    in the underlying (native) objects being retained by the OS. Could be
    something like that. You may have to look beyond the JVM and see what
    the rest of the system is allocating on your behalf.

    I'm not an expert in Windows heap analysis by any means, but if you find
    some good info debugging Windows heaps please post up what you find. :)
    Mark Space, Oct 26, 2007
    #5
  6. Alan Morgan

    Alan Morgan Guest

    In article <3Q9Ui.2598$>,
    Mark Space <> wrote:
    >Alan Morgan wrote:
    >
    >> and this won't change. However, Process Explorer insists that my app,
    >> which started off using 30MB of private memory, is now using 60MB. Forcing
    >> a GC via JProfiler doesn't do anything to change this.
    >>
    >> Obviously using JProfiler is going change the system behavior and mess
    >> with these numbers blah blah Heisenberg. I realize this is not an exact
    >> science.

    >
    >Roedy's link explains that not calling dispose() on GUI objects results
    >in the underlying (native) objects being retained by the OS.


    Mmm. I'm not using GUI objects but the same principles could apply to
    other objects. I'll see if Purity can give me any information there.

    Alan
    --
    Defendit numerus
    Alan Morgan, Oct 26, 2007
    #6
  7. On 26.10.2007 02:24, Alan Morgan wrote:
    > In article <3Q9Ui.2598$>,
    > Mark Space <> wrote:
    >> Alan Morgan wrote:
    >>
    >>> and this won't change. However, Process Explorer insists that my app,
    >>> which started off using 30MB of private memory, is now using 60MB. Forcing
    >>> a GC via JProfiler doesn't do anything to change this.
    >>>
    >>> Obviously using JProfiler is going change the system behavior and mess
    >>> with these numbers blah blah Heisenberg. I realize this is not an exact
    >>> science.

    >> Roedy's link explains that not calling dispose() on GUI objects results
    >> in the underlying (native) objects being retained by the OS.

    >
    > Mmm. I'm not using GUI objects but the same principles could apply to
    > other objects. I'll see if Purity can give me any information there.


    Did you run the JVM with verbose GC trace? Did it tell anything
    interesting?

    Btw, 60MB does not sound much nowadays. I believe the JVM's default for
    -Xmx is 64MB so you could expect it to grow a bit more without having
    to worry.

    Kind regards

    robert
    Robert Klemme, Oct 26, 2007
    #7
  8. Alan Morgan

    kohlerm Guest

    On 26 Okt., 00:41, (Alan Morgan) wrote:
    > In article <>,
    > Daniel Pitts <> wrote:
    >
    > >Alan Morgan wrote:
    > >> I have a Java app, running on Windows, with a medium amount
    > >> of C++ wrapper code doing various arcane and boring things.
    > >> JProfiler swears that there isn't a memory leak in the Java.
    > >> Purify claims that there isn't a memory leak in the C++. According
    > >> to ProcessExplorer, however, we leak memory (or rather, the
    > >> Private Byte and Working Set keep rising).

    >
    > >Only assume you're leaking memory if over a sufficient time period, you
    > >get OOM exceptions. Java is a Garbage Collected environment, which
    > >means that some objects may just hang around until the GC decides its
    > >time to clean them up. Looking at the java processes memory consumption
    > >doesn't tell you what is actually in use. The garbage collector usually
    > >doesn't try very hard until the used memory gets to be very close to
    > >"full" for the currently allocated heap size.

    >
    > I'm aware of that, but there may be some subtlties in the Java GC that
    > I'm missing. JProfiler claims that the heap never grows beyound about
    > 10MB. I see regular garbage collections occurring which generally reduce
    > my consumption from about 9MB to about 6MB. I can run the system all day
    > and this won't change. However, Process Explorer insists that my app,
    > which started off using 30MB of private memory, is now using 60MB. Forcing
    > a GC via JProfiler doesn't do anything to change this.
    >
    > Obviously using JProfiler is going change the system behavior and mess
    > with these numbers blah blah Heisenberg. I realize this is not an exact
    > science.
    >
    > Alan
    > --
    > Defendit numerus


    This looks like that the leak is not in Java.
    To be sure the easiest way to find out whether it's a leak in Java is
    to get
    the SAP Memory Analyzer at https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Java/Java Memory Analysis.
    It's free and will be open sourced soon(check my blog here
    https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/7637)

    Regards,
    Markus
    kohlerm, Oct 26, 2007
    #8
  9. Alan Morgan wrote:

    >
    > Mmm. I'm not using GUI objects but the same principles could apply to
    > other objects. I'll see if Purity can give me any information there.
    >
    > Alan


    You may also want to take a look at some of the IO classes with
    associated close() methods... these objects often have (in some cases
    significant) native memory associated with them. If you explicitly call
    close() the native memory is freed; if you don't, the memory doesn't get
    freed until the object finaliser gets called (which if the object has
    been promoted to the old area may never happen). I've seen one deviant
    case where we got OutOfMemory because of this even though there was
    plenty of free memory in the Java heap.

    You may be able to allay this particular problem by tweaking GC
    parameters (if it's outside your code) - as you can cause objects to
    live for longer without getting promoted if this is the problem.
    However (IMO) best practice is always to call a close() or dispose()
    method if it exists (preferably in a finally block...)

    Dave
    David Gourley, Oct 29, 2007
    #9
    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. Aaron Boxer
    Replies:
    2
    Views:
    737
    Roedy Green
    May 10, 2004
  2. s.subbarayan

    Dynamic memory allocation and memory leak...

    s.subbarayan, Mar 18, 2005, in forum: C Programming
    Replies:
    10
    Views:
    701
    Eric Sosman
    Mar 22, 2005
  3. Replies:
    11
    Views:
    557
  4. sqlnovice

    Memory Leak in .Net app

    sqlnovice, Oct 10, 2008, in forum: ASP .Net
    Replies:
    2
    Views:
    412
    harborsparrow
    Oct 12, 2008
  5. Julien Schmurfy

    Find memory leak in 1.9 app

    Julien Schmurfy, Jan 15, 2011, in forum: Ruby
    Replies:
    5
    Views:
    340
    Charles Oliver Nutter
    Jan 18, 2011
Loading...

Share This Page