Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Forcing Garbage collection  RSS feed

 
Raja Kannappan
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've developed a help viewer for our application.
Whenever I open my help viewer from our application, I see that it is eating upto 5MB of available memory. But when the help viewer window is closed it not releasing the memory back. It seems that Garbage collection is guaranteed to run only when the VM is closed. But here the virtual machine is closed only when my application is closed. So, I'm unable to reclaim my memory back. So, what happens is after running for 10 times, I couldn't open the help viewer and it throws java.lang.OutofMemoryError
I tried to force garbage collection within my helpviewer but it didn't succeed. Whenever I close my helpviewer using the exit button control comes here and I'm doing this:
public void
actionPerformed(ActionEvent e)
{
AbstractButton absButton = (AbstractButton)e.getSource();
if(absButton.getActionCommand()=="exit")
{
frame.setVisible(false);
frame = null;
hs = null;
hb = null;
forwardStack = null;
backwardStack = null;
currentStack = null;
contentViewer = null;
navigatorView = null;
System.runFinalization();
System.gc();
}
}
My finalize() method looks like this:
protected void
finalize() throws Throwable
{
hs = null;
hb = null;
frame = null;
forwardStack = null;
backwardStack = null;
currentStack = null;
contentViewer = null;
navigatorView = null;
super.finalize();
}
Does anybody have any suggestion on how to improve this and force garbage collection?
Thanks,
- Raja.
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can't force garbage collection. Since garbage collection is a memory and time intensive process, you forcing garbage collection would effect the performance of other applications running in the same JVM. Imagine a process that had System.gc() in an infinite loop! System.gc() should be thought of as a suggestion to the JVM. But it is a suggestion that the JVM can choose to ignore.
 
Blake Minghelli
Ranch Hand
Posts: 331
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
System.gc() is not gauranteed to run garbage collection. Instead of trying to set all references to null, use your frame's dispose() method which should close your screen and release its resources.
 
Raja Kannappan
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried doing frame.dispose(). It released the memory. It worked fine for me.
Thanks a lot for your reply,
- Raja.
 
Chris Smith
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One definite way to improve the performance of anything garbage collection related is to get rid of your finalizers. Setting variables to null in a finalizer is the most counter-productive thing you can do. You force objects to stick around for longer than they need to, just so you can set their references to null. Had you not written the finalize() method, the object would already be gone, and its non-null references would not matter.
The finalize() method is the one thing that can make an object stick around longer than it otherwise would... if you're over-using them, this may account for the persistence of objects even after you think they should be gone.
For more tips on getting the most out of garbage collection, see the last part of http://jinx.swiki.net/59
Incidentally, while System.gc() may or may not "technically" be merely a suggestion (it depends on how you interpret the wording of the API specification), it would make for an inexcusable QOI issue if the system really ignored it.
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the API:

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. (my emphasis)

A JVM that always ran gc when called would be a very poorly designed JVM. If the JVM knows that it just ran garbage collection and it has plenty of free space, why should it run garbage collection again? Since garbage collection is very expensive to run, this would be an inefficient use of resources and would effect every program currently running in that JVM. Anyone who has run performance tuning on an EJB server knows that garbage collection running when it isn't needed will screw up your performance more than some poorly coded EJBs.
[ September 16, 2002: Message edited by: Thomas Paul ]
 
Shubhrajit Chatterjee
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
GC will definitely be called before the JVM throws a out of memory error. It must happen that you are storing the references of your objects somewhere ... check your code....
 
Chris Smith
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thomas, how about you continue on to the next sentence; the one that provides the contract for the method. Since you didn't quote it, I will. It says: "When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects."
There are certain situations in which the virtual machine's "best effort" may be nothing at all. To take a simple example, perhaps the garbage collector is using some kind of weak/strong ref-counting scheme, so there is no deferred effort that can be performed. A little more realistically, perhaps there is already a concurrent collection in progress and parallel garbage collection is not implemented (as it isn't in all virtual machines prior to 1.4.1) or is not enabled.
However, the API docs clearly require that a "best effort" be made. I don't believe that deciding not to collect garbage simply because there's plenty of free space already constitutes a "best effort". I believe that the existence of situations in which it really is impossible to perform work on garbage collection reconciles the two distinct requirements of the API docs: that Runtime.gc() is a suggestion, and yet that it requires a best effort to be made.
You're right: excessive garbage collection does not do good for performance, and in the extreme it can consume a large part of CPU time if you ask to do it too often. That doesn't mean that Runtime.gc() should be ignored; it means that programmers should be cautious about using it.
Runtime.gc() was intended for time-critical code in which it is perfectly okay to delay now so long as we don't need to stop for collection at some later time. In such an environment, how can you say that the JVM would be wise to ignore an explicit request that it make a "best effort" to collect all unused objects and reclaim their memory? Sure, it doesn't make sense to request garbage collection at a specific time in an EJB container, or pretty much any other non-interactive application. So, don't call it!
I'm all for the advice to leave garbage collection alone and trust the JVM to manage it when it's needed... but I'm not in favor of misleading anyone on the intended functionality of a standard API call.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!