«

How memory leaks in java. What are the different ways in which
memory can leak. I know of tools which eliminate the leaks,
but I want to know what causes leaks, so that I can practice
not to write a program which leaks memory?

On 24 Apr 2004 07:44:19 -0700, (aruna) wrote or
quoted :

>How memory leaks in java. What are the different ways in which
>memory can leak. I know of tools which eliminate the leaks,
>but I want to know what causes leaks, so that I can practice
>not to write a program which leaks memory?

see http://mindprod.com/jgloss/packratting.html

Strictly speaking, you can't have a memory leak in Java, at least not
in the same sense you can in C++.


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Roedy Green wrote:
> On 24 Apr 2004 07:44:19 -0700, (aruna) wrote or
> quoted :
>
>
>>How memory leaks in java. What are the different ways in which
>>memory can leak. I know of tools which eliminate the leaks,
>>but I want to know what causes leaks, so that I can practice
>>not to write a program which leaks memory?
>
>
> see http://mindprod.com/jgloss/packratting.html
>
> Strictly speaking, you can't have a memory leak in Java, at least not
> in the same sense you can in C++.

Yes. In C++ you have memory leaks when you lose all pointers to a block
of memory and you have not yet freed the block. In java this can't
happen, because an unreachable block of memory is eligible for garbage
collection. In java you can have the reverse, where you have references
to 'dead' objects that you don't use but that still be reached from the
root set of pointers, so they can't be GCed.
--
Daniel Sjöblom
Remove _NOSPAM to reply by mail

In article <>,
Roedy Green <> wrote:

>:On 24 Apr 2004 07:44:19 -0700, (aruna) wrote or
>:quoted :
>:
>:>How memory leaks in java. What are the different ways in which
>:>memory can leak. I know of tools which eliminate the leaks,
>:>but I want to know what causes leaks, so that I can practice
>:>not to write a program which leaks memory?
>:
>:see http://mindprod.com/jgloss/packratting.html
>:
>:Strictly speaking, you can't have a memory leak in Java, at least not
>:in the same sense you can in C++.

Sun would have us believe that it's "theoretically" impossible to get a
memory leak. But that's flatly not true. It can happen in complex
objects beyond just Swing components. Been there, done that. And there
are commercial tools aimed at helping find leaks so that you can resolve
them. We happen to use OptimizeIt, now sold by Borland.

The garbage collection system truly is an improvement over what C++
users have had to do, IMO. And many common references will in fact get
cleaned up. We had some concerns about whether a HashMap, ArrayList or
Vector, for instance, needed to be cleared before it would get
collected. Our testing showed that it got collected sooner if we
cleared the contents, but that it would still get collected even if we
didn't. I rather suspect that simple "circular" references, where two
objects refer to each other, but neither can be found by my code, also
get collected properly, though we weren't concerned about that (that is,
after all, one of the strengths of Java). But we fought a long, hard
battle over much more complex references eating up our memory, so we
eventually added dispose() methods in a number of our own complex
(non-GUI) classes to resolve the problem by ensuring that our references
got zapped, or caused subordinate objects to do their own dispose()
kinds of work.

The glossary reference to Threads brings up another area I stumbled
across, too. I worked for a long time trying to figure out why my
program's JWindow used at startup as a splash screen never got
collected. Then I finally discovered it was Thread related. The old
rule about quitting the JVM after all non-daemon Threads have finished
was the clue, but it took a while for me to add things up. My app's
main startup method displayed that JWindow, then built and displayed the
main app JFrame, then closed the JWindow. All attempts to call
dispose() on it, to remove its components, everything failed -- until I
realized that it left a Thread behind where my main() method was that
caused the entire problem. So now, I create the window and build it up,
but the calls to show and hide it are both done via Runnable. And it
gets collected fairly soon after! Lesson learned.

= Steve =
--
Steve W. Jackson
Montgomery, Alabama

On Mon, 26 Apr 2004 13:52:21 -0500, "Steve W. Jackson"
<> wrote or quoted :

>Sun would have us believe that it's "theoretically" impossible to get a
>memory leak.

read the entry at http://mindprod.com/jgloss/packratting.html

There are definitely ways you can inadvertently hold onto ram, but
that is because you have pointers to it, so you can't very well blame
Java for not being able to mindread that you will never need these
later.

A leak is where you have memory tied up with nothing pointing to it.

There are also some problems with the underlying GUI being too stupid
to do its own GC, hence the dispose kludge.



--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Mon, 26 Apr 2004 13:52:21 -0500, "Steve W. Jackson"
<> wrote or quoted :

> So now, I create the window and build it up,
>but the calls to show and hide it are both done via Runnable

I thought those had to be done from the Swing thread, or are you
creating your own new Swing thread somehow?



--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

> >How memory leaks in java. What are the different ways in which
> >memory can leak. I know of tools which eliminate the leaks,
> >but I want to know what causes leaks, so that I can practice
> >not to write a program which leaks memory?

http://www.xdweb.net/~dibblego/java/...swers.html#q22

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

In article <>,
Roedy Green <> wrote:

>:On Mon, 26 Apr 2004 13:52:21 -0500, "Steve W. Jackson"
>:<> wrote or quoted :
>:
>:>Sun would have us believe that it's "theoretically" impossible to get a
>:>memory leak.
>:
>:read the entry at http://mindprod.com/jgloss/packratting.html
>:
>:There are definitely ways you can inadvertently hold onto ram, but
>:that is because you have pointers to it, so you can't very well blame
>:Java for not being able to mindread that you will never need these
>:later.
>:
>:A leak is where you have memory tied up with nothing pointing to it.
>:
>:There are also some problems with the underlying GUI being too stupid
>:to do its own GC, hence the dispose kludge.
>:
>:
>:
>:--
>:Canadian Mind Products, Roedy Green.
>:Coaching, problem solving, economical contract programming.
>:See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

I did read that. But the simple fact is that the general belief among
those entering the Java development community is that it's not necessary
to take care of all references to objects you no longer need. That
leads people to experience memory leaks since they believe they can have
all kinds of internal references magically cleaned up for them (and also
leads some to have undeserved negative views of Java). But as your
entry points out, even Swing itself suffers from the fact that this
isn't quite true if you don't dispose components carefully.

= Steve =
--
Steve W. Jackson
Montgomery, Alabama

In article <>,
Roedy Green <> wrote:

>:On Mon, 26 Apr 2004 13:52:21 -0500, "Steve W. Jackson"
>:<> wrote or quoted :
>:
>:> So now, I create the window and build it up,
>:>but the calls to show and hide it are both done via Runnable
>:
>:I thought those had to be done from the Swing thread, or are you
>:creating your own new Swing thread somehow?
>:

There was something in the Java tutorial on Thread usage back when I was
just learning where they said it was "kinda OK" to do the main GUI from
within the main thread. The current tutorial backs off of that. But
based on that, I used what their tutorial said was safe for my only
JFrame, which was to fully build it in my main() method and then call
pack() and show() on it. Hey, Sun said it was OK!

What I failed to realize was that it would get me in trouble if I did it
more than once... So when I finally realized what my trouble was, I
changed my main class to create both GUI elements (the splash window and
the app's lone JFrame), but not to display them from that code.
Instead, I create a Runnable and pass it to SwingUtilities.invokeLater
so that it is indeed run on the EDT as Swing wants me to do.

Now, however, I find out that my consistent use of show() and hide() on
Window subclasses is being deprecated in 1.5. Drat!

= Steve =
--
Steve W. Jackson
Montgomery, Alabama

On Tue, 27 Apr 2004 15:39:46 -0500, "Steve W. Jackson"
<> wrote or quoted :

>What I failed to realize was that it would get me in trouble if I did it
>more than once... So when I finally realized what my trouble was, I
>changed my main class to create both GUI elements (the splash window and
>the app's lone JFrame), but not to display them from that code.
>Instead, I create a Runnable and pass it to SwingUtilities.invokeLater
>so that it is indeed run on the EDT as Swing wants me to do.

Bong!! I have always assumed the thread that ran main was ALSO the
Swing thread and the AWT thread. I gather this is NOT so.

This may explain my frustration with programs that would not stop even
after I closed all the Frames.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.