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?

Advertisements

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.

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.

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.

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.

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?)

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.

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.

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

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 Productshttp://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.

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.

On Fri, 29 Jun 2012 10:19:59 -0700 (PDT), 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.
>
>> 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.

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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!