Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15716 > unrolled thread

Closing/Despose of JFrame

Back to article view | Back to comp.lang.java.programmer

Contents

  Closing/Despose of JFrame Jesper Johnsen <jsjohnsen.dk@gmail.com> - 2012-06-28 06:38 -0700
    Re: Closing/Despose of JFrame markspace <-@.> - 2012-06-28 07:22 -0700
      Re: Closing/Despose of JFrame Lew <lewbloch@gmail.com> - 2012-06-28 09:47 -0700
        Re: Closing/Despose of JFrame Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-28 23:31 +0000
          Re: Closing/Despose of JFrame Lew <lewbloch@gmail.com> - 2012-06-28 17:42 -0700
        Re: Closing/Despose of JFrame Gene Wirchenko <genew@ocis.net> - 2012-06-28 19:55 -0700
          Re: Closing/Despose of JFrame Lew <lewbloch@gmail.com> - 2012-06-29 10:19 -0700
            Re: Closing/Despose of JFrame Gene Wirchenko <genew@ocis.net> - 2012-06-29 13:24 -0700
              Re: Closing/Despose of JFrame Lew <lewbloch@gmail.com> - 2012-06-29 13:36 -0700
        Re: Closing/Despose of JFrame Roedy Green <see_website@mindprod.com.invalid> - 2012-06-29 05:31 -0700
    Re: Closing/Despose of JFrame Lew <lewbloch@gmail.com> - 2012-06-28 12:46 -0700
    Re: Closing/Despose of JFrame "John B. Matthews" <nospam@nospam.invalid> - 2012-06-28 22:32 -0400

#15716 — Closing/Despose of JFrame

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){}
    }
    }

}

[toc] | [next] | [standalone]

#15717

On 6/28/2012 6:38 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?


Why? Because the garbage collector never needs to remove the object. 
You're using 20mb out of maybe 100mb to 1000mb or more?  So the garbage 
collector looks at that and says "plenty o' room left!" and doesn't run.

It's weird if you're used to having explicit control over object 
destruction, but it works.  More importantly it's efficient.   Waiting, 
and then removing lots of objects at once, is actually best for 
throughput in the long run.

If you really need different behavior, check out Oracle's documentation 
on tuning the garbage collector.  You can choose what I believe is 
called an incremental garbage collector which will work more like what 
you are thinking.

<http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html>

Found via Google with search terms "java garbage collection tuning". 
Learn to STFW.

[toc] | [prev] | [next] | [standalone]

#15725

markspace wrote:
> 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?
> 
> 
> Why? Because the garbage collector never needs to remove the object. 
> You're using 20mb out of maybe 100mb to 1000mb or more?  So the garbage 
> collector looks at that and says "plenty o' room left!" and doesn't run.
> 
> It's weird if you're used to having explicit control over object 
> destruction, but it works.  More importantly it's efficient.   Waiting, 
> and then removing lots of objects at once, is actually best for 
> throughput in the long run.
> 
> If you really need different behavior, check out Oracle's documentation 
> on tuning the garbage collector.  You can choose what I believe is 
> called an incremental garbage collector which will work more like what 
> you are thinking.
> 
> <http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html>
> 
> Found via Google with search terms "java garbage collection tuning". 
> Learn to STFW.

Shut the front window? :-)

Both oracle.com and https://www.ibm.com/developerworks/java/ have 
excellent articles and white papers on Java garbage collection, how it 
works and how you can fine tune it.

Make sure you have a problem before you try to solve it, but it is 
always useful to gather knowhow.

The default generational garbage collector works well, especially 
for idiomatic Java. As Brian Goetz points out in his Developerworks 
articles, the allocation cost in the heap is very tiny, on the order of 
a dozen or so machine instructions. Deallocation is likewise not 
very expensive for short-lived objects. Young objects live in the 
young generation heap, and dead ones are ignored during 
minor GCs. 

If most objects are short-lived, as should be true if one follows 
best practices for scoping variables, then most GC cycles will gather 
about 3% of live objects, ignoring the 97% of unreachable ones. 
This is a very fast copy and shouldn't burden your throughput 
very much.

When objects survive enough minor GC cycles, they move to 
the tenured generation, a different area of heap. These are only 
collected during major GC cycles, which use different and somewhat 
slower algorithms under default setup. The major cycles are the 
ones we tend to notice. So if an object is going to survive to tenure, 
aim to have it survive for a very long time thereafter. Otherwise 
use idioms that help objects die young.

For example, dying young:

public class Example
{
 Collection<Foo> foos = getSomeFoos();
 public void run()
 {
  for (Foo foo : foos)
  {
    Bar bar = foo.obtainBar();
    // do whatever with 'bar'
    // 'bar' falls out of scope
    // if nothing else points to the same object
    // it is gone in the next minor GC
  }
 }
}

Dying old:

public class Example
{
 Collection<Foo> foos = getSomeFoos();
 Bar bar; // the elephant in the room
 public void run()
 {
  for (Foo foo : foos)
  {
   bar = foo.obtainBar();
    // do whatever with 'bar'
    // 'bar' does not fall out of scope
    // The last reference from the loop lasts as 
    // long as this instance does, and could 
    // tenure the 'Bar' it points to
  }
 }
}

So coding things the first way, which chance are is 
more correct logically, tends to reduce the impact of 
GC on performance. It tilts the GC towards very rapid, 
almost negligible young-generation collections and 
less toward the slower, more intrusive tenured-generation 
collections.

Read widely and carefully. There are some notable urban 
legends out there, such as the advice to set all references 
to 'null' when finished with them. There are specific times 
to do so, such as when a collection such as a 'Stack' is 
holding hidden references ("packratting", or the Java version 
of a memory leak). Otherwise it's just superstition.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15734

Lew <lewbloch@gmail.com> wrote:
> Dying old:
> public class Example
> {
>  Collection<Foo> foos = getSomeFoos();
>  Bar bar; // the elephant in the room
>  public void run()
>  {
>   for (Foo foo : foos)
>   {
>    bar = foo.obtainBar();
>     // do whatever with 'bar'
>     // 'bar' does not fall out of scope
>     // The last reference from the loop lasts as 
>     // long as this instance does, and could 
>     // tenure the 'Bar' it points to
>   }
>  }
> }
> [...]
> There are some notable urban 
> legends out there, such as the advice to set all references 
> to 'null' when finished with them. There are specific times 
> to do so, such as when a collection such as a 'Stack' is 
> holding hidden references ("packratting", or the Java version 
> of a memory leak). [...]

...or right after the loop in above "dying old"-Example, if for
whatever reason there really was some need to have "bar" as a
field, instead of as a local var within the loop.

[toc] | [prev] | [next] | [standalone]

#15736

Andreas Leitgeb wrote:
> Lew wrote:
> > Dying old:
> > public class Example
> > {
> >  Collection<Foo> foos = getSomeFoos();
> >  Bar bar; // the elephant in the room
> >  public void run()
> >  {
> >   for (Foo foo : foos)
> >   {
> >    bar = foo.obtainBar();
> >     // do whatever with 'bar'
> >     // 'bar' does not fall out of scope
> >     // The last reference from the loop lasts as 
> >     // long as this instance does, and could 
> >     // tenure the 'Bar' it points to
> >   }
> >  }
> > }
> > [...]
> > There are some notable urban 
> > legends out there, such as the advice to set all references 
> > to 'null' when finished with them. There are specific times 
> > to do so, such as when a collection such as a 'Stack' is 
> > holding hidden references ("packratting", or the Java version 
> > of a memory leak). [...]
> 
> ...or right after the loop in above "dying old"-Example, if for
> whatever reason there really was some need to have "bar" as a
> field, instead of as a local var within the loop.

True, but dangerous. If you are nulling out the reference after the loop 
anyway, there is a low probability that a member variable is the right 
scope. I can think of reasons why one might do that, but they all seem 
like tangled and ill-advised code to me.

The scope and lifetime of the variable should match the scope and 
lifetime of the need for its reference. The scenario you describe seems 
to violate that. I say "seems to" because sure, there very well could be 
cases for it. But they all would (or should) fit into the "scope and lifetime 
should match" rule. So if you do see a situation where the scope is the 
instance, and/or the lifetime matches that of the enclosing instance, then 
a member variable is correct even should Lew feel that your code is tangled 
and ill advised.

OTOH, you shouldn't be too quick to dismiss my insight into the matter.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15739

On Thu, 28 Jun 2012 09:47:55 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

[snip]

>Read widely and carefully. There are some notable urban 
>legends out there, such as the advice to set all references 
>to 'null' when finished with them. There are specific times 
>to do so, such as when a collection such as a 'Stack' is 
>holding hidden references ("packratting", or the Java version 
>of a memory leak). Otherwise it's just superstition.

     Ah, not quite.  In Visual FoxPro, at least in some versions, the
releasing of an object or an array with object references would result
in a memory leak.  Setting to null was a workaround for that.  I would
not be surprised if it happened in some other languages, too. However,
I would not do it unless it were required.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15750

Gene Wirchenko wrote:
> Lew wrote:
> 
> [snip]
> 
> >Read widely and carefully. There are some notable urban 
> >legends out there, such as the advice to set all references 
> >to 'null' when finished with them. There are specific times 
> >to do so, such as when a collection such as a 'Stack' is 
> >holding hidden references ("packratting", or the Java version 
> >of a memory leak). Otherwise it's just superstition.
> 
>      Ah, not quite.  In Visual FoxPro, at least in some versions, the

I'm sorry, Visual FoxPro?

> releasing of an object or an array with object references would result
> in a memory leak.  Setting to null was a workaround for that.  I would
> not be surprised if it happened in some other languages, too. However,
> I would not do it unless it were required.

I'm not so sure that rules of thumb derived from Visual FoxPro are 
applicable here.

The urban legends to which I referred are specifically about Java.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15752

On Fri, 29 Jun 2012 10:19:59 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

>Gene Wirchenko wrote:
>> Lew wrote:
>> 
>> [snip]
>> 
>> >Read widely and carefully. There are some notable urban 
>> >legends out there, such as the advice to set all references 
>> >to 'null' when finished with them. There are specific times 
>> >to do so, such as when a collection such as a 'Stack' is 
>> >holding hidden references ("packratting", or the Java version 
>> >of a memory leak). Otherwise it's just superstition.
>> 
>>      Ah, not quite.  In Visual FoxPro, at least in some versions, the
>
>I'm sorry, Visual FoxPro?

     A mid-level DBMS developed by Microsoft.
>
>> releasing of an object or an array with object references would result
>> in a memory leak.  Setting to null was a workaround for that.  I would
>> not be surprised if it happened in some other languages, too. However,
>> I would not do it unless it were required.
>
>I'm not so sure that rules of thumb derived from Visual FoxPro are 
>applicable here.

     I was countering your superstition statement.

>The urban legends to which I referred are specifically about Java.

     All you mentioned was that they were notable.  You did not
mention Java.  We do not discuss only Java here.  And some cargo cult
programming can leap from language to language.

     I have seen the set-to-null requirement stated for VFP (with a
reason) and VB 6 (without a reason).  Now, you say it is in Java, too,
with limited times when it is necessary.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15753

Gene Wirchenko wrote:
> Lew wrote:
> 
> >Gene Wirchenko wrote:
> >> Lew wrote:
> >> 
> >> [snip]
> >> 
> >> >Read widely and carefully. There are some notable urban 
> >> >legends out there, such as the advice to set all references 
> >> >to 'null' when finished with them. There are specific times 
> >> >to do so, such as when a collection such as a 'Stack' is 
> >> >holding hidden references ("packratting", or the Java version 
> >> >of a memory leak). Otherwise it's just superstition.
> >> 
> >>      Ah, not quite.  In Visual FoxPro, at least in some versions, the
> >
> >I'm sorry, Visual FoxPro?
> 
>      A mid-level DBMS developed by Microsoft.

I know what it is. I was questioning the relevance to a discussion of Java idioms.

> >> releasing of an object or an array with object references would result
> >> in a memory leak.  Setting to null was a workaround for that.  I would
> >> not be surprised if it happened in some other languages, too. However,
> >> I would not do it unless it were required.
> >
> >I'm not so sure that rules of thumb derived from Visual FoxPro are 
> >applicable here.
> 
>      I was countering your superstition statement.

Superstition is bad engineering and should be countered.

> >The urban legends to which I referred are specifically about Java.
> 
>      All you mentioned was that they were notable.  You did not

The context was a discussion of Java.

> mention Java.  We do not discuss only Java here.  And some cargo cult

This particular discussion was only about Java. The OP was asking about 
removing JFrame instances from memory. That is not a general programming
question.

My point about 'null' was specific to Java because the topic was.

Don't be disingenuous.

> programming can leap from language to language.

The reasons for or against setting to null are not the same, as 
VFP is not a memory-managed language.

>      I have seen the set-to-null requirement stated for VFP (with a
> reason) and VB 6 (without a reason).  Now, you say it is in Java, too,
> with limited times when it is necessary.

Different languages, different reasons, different worlds.

The point about avoiding superstition does cross universes.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15744

On Thu, 28 Jun 2012 09:47:55 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

> Otherwise it's just superstition.

quoting from http://mindprod.com/jgloss/null.html#GC

Null and Garbage Collection

 Obviously, if you null a reference it becomes a candidate for GC
sooner. In ordinary Java code, it is most common that you would exit
the method almost immediately after such a nulling, so it buys you
nothing for local variables allocated during the method invocation. 

 However, if you had some very complicated method, it could pay to
null half-way through execution. But that being true is a symptom that
you probably would want to refactor the routine in two, which would
then most likely obviate the nulling.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15730

Stefan Ram wrote:
> Stefan Ram writes:
> >Jesper Johnsen writes:
> >>JFrame frame = new JFrame("Test");
> >public class Main implements java.lang.Runnable
> 
> public class Main implements java.lang.Runnable
> { public void run()
>   { for( ;; )
>     { java.lang.System.out.println( java.lang.Runtime.getRuntime().freeMemory() + " Bytes free." );
>       javax.swing.JFrame frame  = new javax.swing.JFrame();
>       frame.pack(); frame.setVisible( true ); frame.dispose(); frame = null; }}
> 
>   public static void main( final java.lang.String[] args ) throws java.lang.Throwable
>   { javax.swing.SwingUtilities.invokeAndWait( new Main() ); }}
> 
>   The above program shows declining amounts of free memory for
>   some time. Then, a gc seems to be triggered, which reclaims
>   a part of the memory. After several such gcs, there is less
>   and less memory reclaimed and one feels that soon an
>   unrecoverable out-of-memory error will happen. But then a
>   real deep major gc seems to be triggered that seems to
>   reclaim all or nearly all of the memory! (I stopped it then,
>   maybe someone wants to have this running overnight?)

Also there are answers to other incarnations of this multipost 
that go into how this all works.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15738

In article <gc-20120628210556@ram.dialup.fu-berlin.de>,
 ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> >Jesper Johnsen <jsjohnsen.dk@gmail.com> writes:
> >>JFrame frame = new JFrame("Test");
> >public class Main implements java.lang.Runnable
> 
> public class Main implements java.lang.Runnable
> { public void run()
>   { for( ;; )
>     { java.lang.System.out.println( 
>     java.lang.Runtime.getRuntime().freeMemory() + " Bytes free." );
>       javax.swing.JFrame frame  = new javax.swing.JFrame();
>       frame.pack(); frame.setVisible( true ); frame.dispose(); frame = null; 
>       }}
> 
>   public static void main( final java.lang.String[] args ) throws 
>   java.lang.Throwable
>   { javax.swing.SwingUtilities.invokeAndWait( new Main() ); }}
> 
>   The above program shows declining amounts of free memory for
>   some time. Then, a gc seems to be triggered, which reclaims
>   a part of the memory. After several such gcs, there is less
>   and less memory reclaimed and one feels that soon an
>   unrecoverable out-of-memory error will happen. But then a
>   real deep major gc seems to be triggered that seems to
>   reclaim all or nearly all of the memory! (I stopped it then,
>   maybe someone wants to have this running overnight?)

I cited a similar experiment here, using an artificially small heap to 
exaggerate the effect:

<news:nospam-8C752E.22024228062012@news.aioe.org>
<https://groups.google.com/d/msg/comp.lang.java.help/ylUG68cHsWQ/h1FMBzKirkwJ>

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web