Remove JFrame from memory

[Jesper Johnsen]

How do I remove an object lets say a JFrame from memory?
I know that the garbage collector handles this - but this simple example does not release itself...
java.exe uses 10mb in the first wait stage, this increases to 20mb when the JFrame is shown, but the memory usage never returns to the initial 10mb.
So the garbage collector never removes the object from memory - why?

package jframetest;

import javax.swing.JFrame;

public class JFrameTest {

public static void main(String[] args) {
try{
Thread.sleep(5000);
}catch(Exception Ex){}
JFrame frame = new JFrame("Test");
frame.setVisible(true);
try{
Thread.sleep(5000);
}catch(Exception Ex){}
frame.setVisible(false);
frame.dispose();
frame = null;
while(1==1){
try{
Thread.sleep(100);
}catch(Exception Ex){}
}
}

}

[Knute Johnson]

I don't know but it doesn't really matter. Calling dispose() on it will
work fine in a real world program.

--

Knute Johnson

[Eric Sosman]

Your program's final loop is pretty much a no-op, and probably
doesn't create many new objects -- it may create none at all. If
the program doesn't use up memory for new objects, the memory it
already has is sufficient and there is no reason for the garbage
collector to run around trying to find more.

Even if collection occurs and the JFrame's memory is recycled,
Java is likely to retain that memory to re-use for other new objects.
If you look at Java's memory consumption "from the outside," with
an O/S tool of some kind, you cannot tell the difference between
memory occupied by Java's objects and memory that currently holds no
objects (but is available for making new ones). The JFrame may or
may not have been collected; you cannot tell from outside Java.

You could use command-line flags to get Java to tell you about
what the garbage collector does. The flags tend to vary from one
version to the next (because the collector changes, too), and you
probably can't discover which particular objects are and aren't
collected. But you can at least see whether GC runs at all after
you dispose the JFrame.

Another possibility would be to change your program a little
so it informs you when the JFrame is collected. One way to do this
would be to make your own subclass of JFrame, with a finalize()
method that alerts you when it's collected:

class MyFrame extends JFrame {
MyFrame(String title) {
super(title);
}

// I do not usually recommend implementing finalize(),
// but here we're just using it for exploration.
protected void finalize() throws Throwable {
try {
System.err.println("Finalizing " + this);
} finally {
super.finalize();
}
}
}

Then you can use `JFrame frame = new MyFrame("test");' and run
the program; if the garbage collector reaps the frame, you will
see a message on the standard error stream. As I mentioned above,
the garbage collector might not run at all if the program consumes
little memory, so you might want to burn some by creating objects
in your final loop, something like:

while (true) {
byte[] junk = new byte[1000000];
try {
Thread.sleep(100);
} catch (InterruptedException ex) {
// ignore
}
}

With this in place you should see Java's memory consumption rise
at the rate of about 10Mbyte/sec, which should provoke garbage
collection fairly soon. *Then* if you don't see the MyFrame get
finalized there may be a problem to look into -- but so far, you
don't have evidence that anything's wrong.

--
Eric Sosman
eso...@ieee-dot-org.invalid

[Joshua Cranmer]

On 6/28/2012 9:48 AM, Jesper Johnsen wrote:

> How do I remove an object lets say a JFrame from memory? I know that
> the garbage collector handles this - but this simple example does not
> release itself... java.exe uses 10mb in the first wait stage, this
> increases to 20mb when the JFrame is shown, but the memory usage
> never returns to the initial 10mb.

I take it you found this by looking at memory usage in the Task Manager.
For programs that do a lot of custom memory management, a category which
Java falls into, what Task Manager reports is fairly useless.

For various reasons, the "memory" that Java uses can be divided into
several classes:
VM - the amount of virtual memory that the OS has given to Java
committed - the amount of virtual memory that is backable by physical memory
allocated - the amount of virtual memory that is actually used by some
objects in memory.

The number you see in the task manager is most closely correlated to the
first metric (more specifically, it's the amount of memory which isn't
accessible to any other processes). To see the other values, you need to
use Java's internal memory management APIs.

IIRC, Java does what amounts to lazy initialization of the AWT, which
you probably can't uninitialize, so some of the memory usage you see may
be related to the AWT initialization.

In short: you have numbers which are useless and say pretty much nothing.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[Lew]

Jesper Johnsen wrote:
> How do I remove an object lets say a JFrame from memory?

Stop referring to it, then run out of memory.

> I know that the garbage collector handles this - but this simple example does not release itself...
> java.exe uses 10mb in the first wait stage, this increases to 20mb when the JFrame is shown, but the memory usage never returns to the initial 10mb.
> So the garbage collector never removes the object from memory - why?

Others have answered, but the short version (as you would know from reading
the documentation vis-à-vis garbage collection) is that you haven't run out of
heap yet.

> package jframetest;
>
> import javax.swing.JFrame;
>
> public class JFrameTest {
>
> public static void main(String[] args) {
> try{
> Thread.sleep(5000);
> }catch(Exception Ex){}
> JFrame frame = new JFrame("Test");

You need to do GUI actions on the Event Dispatch Thread (EDT),
not the main thread.

> frame.setVisible(true);

Ditto.

> try{
> Thread.sleep(5000);
> }catch(Exception Ex){}
> frame.setVisible(false);

Ditto.

> frame.dispose();
> frame = null;
> while(1==1){
> try{
> Thread.sleep(100);
> }catch(Exception Ex){}
> }
> }
>
> }

--
Lew

[John B. Matthews]

In article <jshrp5$kkh$1...@dont-email.me>,

Knute Johnson <nos...@knutejohnson.com> wrote:

> On 6/28/2012 6:48 AM, Jesper Johnsen wrote:
> > How do I remove an object lets say a JFrame from memory? I know
> > that the garbage collector handles this - but this simple example

> > does not release itself. java.exe uses 10mb in the first wait

> > stage, this increases to 20mb when the JFrame is shown, but the
> > memory usage never returns to the initial 10mb. So the garbage
> > collector never removes the object from memory - why?
>

> [...]

>
> I don't know but it doesn't really matter. Calling dispose() on it
> will work fine in a real world program.

Jesper Johnsen: Knute raises a very practical point.

This Q&A profiles a pathological example that opens and disposes
thousands of JFrame instances, revealing the slow accumulation of
resources committed to the frame's graphics peer on the host side.

<http://stackoverflow.com/q/6309407/230513>

You can repeat the experiment like this:

$ java -Xms30M -Xmx30M -cp build/classes DialogClose &
$ jvisualvm &

It may help to know what motivates your concern.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Jesper Johnsen]

Thank you for a very good reply.

> If the program doesn't use up memory for new objects, the memory it
> already has is sufficient and there is no reason for the garbage
> collector to run around trying to find more.

My program is just a sample, and I was just curious why, the object was not removed. B

> The JFrame may or
> may not have been collected; you cannot tell from outside Java.

As Lew also say I have free Heap space so my object is not GC'ed. and from the memory debugger I can see that my heap space is actually reduced when the object is disposed. So the code is working - and I learned something great

> class MyFrame extends JFrame {
> MyFrame(String title) {
> super(title);
> }
>
> // I do not usually recommend implementing finalize(),
> // but here we're just using it for exploration.
> protected void finalize() throws Throwable {
> try {
> System.err.println("Finalizing " + this);
> } finally {
> super.finalize();
> }
> }
> }

Thank you for this, I will try play with it in some of my larger applications.

- Jesper

[Jesper Johnsen]

Hi

> I take it you found this by looking at memory usage in the Task Manager.

That is correct.

> To see the other values, you need to
> use Java's internal memory management APIs.

I did this today, and I see the difference - Thanks
I can see that the Heap space is released, so everything is as it should be.

Thanks
- Jesper

[Jesper Johnsen]

CLOSED

Thank you all for your time.
It really made it more clear to me what is going on.
And I can really use the input when I continue my journey into the Java world

Best Regads
Jesper Johnsen

[Roedy Green]

On Thu, 28 Jun 2012 06:48:35 -0700 (PDT), Jesper Johnsen
<jsjohn...@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>How do I remove an object lets say a JFrame from memory?
>I know that the garbage collector handles this - but this simple example does not release itself.

Normally GC handles it, but Frames get entangled with the OS and it
does not work. You must use dispose.
See http://mindprod.com/jgloss/jframe.html
http://mindprod.com/jgloss/frame.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
When you get stuck trying to solve a computer program:
1. Go into the kitchen and make coffee.
2. If that fails, go for a walk.
3. If that fails, take a nap.
Why? To avoid being swamped with details, to see the big picture,
to allow in some random noise to kick you out of your thinking rut.

[Lew]

Roedy Green wrote:
> Jesper Johnsen wrote, quoted or indirectly quoted someone who said :

>> How do I remove an object lets say a JFrame from memory?
>> I know that the garbage collector handles this - but this simple example does not release itself.
>
> Normally GC handles it, but Frames get entangled with the OS and it
> does not work. You must use dispose.
> See http://mindprod.com/jgloss/jframe.html
> http://mindprod.com/jgloss/frame.html

GC only handles Java heap memory. All other resources, such as native
memory, file handles, native graphics widgets or anything else besides
heap memory is the programmer's responsibility.

--
Lew

[Lew]

Don't.

You almost never want to override 'finalize()'. To find out what lies outside
that "almost", read /Effective Java/ by Joshua Bloch.

Do not use 'finalize()' until you understand its dangers and its effects on GC.
For example, incorrect use of 'finalize()' overrides can increase the risk of
crashes. It does delay and can prevent the collection of dereferenced instances.

Do not use 'finalize()' lightly.

--
Lew

[Lew]

Jesper Johnsen wrote:
> CLOSED
>
> Thank you all for your time.
> It really made it more clear to me what is going on.
> And I can really use the input when I continue my journey into the Java world

Have you read the suggested tutorials and books and articles in Developerworks
and elsewhere yet?

--
Lew