Garbage_Collection

Garbage Collection

Garbage collection is Java's way of automatically freeing up memory on the heap, without the programmer having to do it.There are many different garbage collection algorithms (HotSpot, for example, does it much better than the others!), but they all have this in common.

Objects become "eligible" for garbage collection when there are no more references to them.

For objects created inside methods will be eligible for garbage collection when the method completes (reference variable goes out of scope) assuming that the object reference was not passed to another method which then stored the reference in an instance variable.

For instance variables (and local variables), an object will be eligible for garbage collection when the reference variable is set to null, or the variable is assigned a different object to reference.

So when an object has NO references to it, It becomes eligible for garbage collection. And that is *usually* all you can ever know about an object. You don't know 'WHEN' the garbage collector will actually run, and reclaim the memory.You are only expected to know when an object 'COULD' be garbage collected. The garbage collector is typically running as a low priority thread, and may "wake up" at intermittent times, or (ideally for most of us) only when memory becomes critically low.

gc()

You can call System.gc(), but this does not force garbage collection to actually occur -- it is merely a suggestion. gc() is a hint that you would like garbage collection to occur -- where the gc algorithm -- WHATEVER IT IS (depends on the Virtual Machine) runs in an attempt to free up the memory used by unreferenced objects.Calling System.gc() (or Runtime.gc()) does not mean it will actually happen.It's just your way of saying to the VM,"If you feel like it, NOW might be a good time to run... if its OK with you,: )".We don't talk about garbage collection of a reference -- only the objects those variables refer to.Take a example-

Cat c = new Cat();

c = null; // now one object is available for collection

But look at this:

c = new Cat();

Cat d = c;

c = null; // no objects are available for collection, because even though the c reference is null, the d reference is still pointing to
that Cat which c was first referring to. So the Cat object is still alive on the heap.

d = null; // now the Cat is finally available for collection. So we say "one" object is available for collection, even though there were two references.

Weak References

Now, in Java2 there is a way where you can find out when an object is available for collection, and you can decide what to do at that point (give your "permission" or continue to hang on to it). This concept is known as "weak references", and lets you have a little more involvement in the garbage collection process (but you still can't actually MAKE garbage collection happen, you can only "suggest" that it should happen.But you can at least ask to be notified before an object is actually swept out. This is not the same as finalize().

finalize()

finalize() was simply a means to have code run just before the object was actually collected, but it was never proven to actually work correctly or consistently, so you shouldn't depend on it. If you want to know when an object's reference count drops to zero, weak references are probably your best hope.finalize() is the method which all objects inherit from object, and the idea behind it was that finalize would be called BEFORE an object was actually garbage collected.The garbage collector runs,notices that an object has an overriden finalize() method that must be called, and it holds off garbage collecting it but schedules its finalize() method to be called. Except it really doesn't always work! The idea was that you would put your clean-up code in here -- things you always wanted to occur as an object was being killed off. But it doesn't really work reliably, so you shouldn't be dependent on it. Finalize might not ever be called, even if the object is gc'd. AND on some older VMs, having a lot of objects with overriden finalize() methods could lead to out-of-memory errors! (because of the way the gc allocated new memory on the heap for the objects which needed to have finalize called-- this is considered a bad implementation decision of some older VMs, but not really a bug).You weren't intended to call finalize(), it would be called on your behalf. You would simply override it, and ideally also call super.finalize().In practice, you should stay away from it and find alternatives.

Garbage Collection with swing Components:

If I create a JPanel with hundreds of components and listeners, the whole kit will eventually be garbage collected as long as my single reference to the root JPanel is dropped, assuming that there are no other references to any of those objects from the execution context.My understanding of the Swing GC issues is that creation of certain components such as top-level windows, focus managers, etc. will invisibly create execution-context references in certain Swing class or instance variables which don't go away and thus prevent those components and their descendants from being collected.This is the case with AWT components also but since Swing has more deeper and wide class hierarchy so any particular swing class may have more referers.

HotSpot

HotSpot gc works differently, and much better than the standard JVM, because it can work incrementally -- instead of one big collection,it can collect little bits at a time which is much less noticeable, and I *think* that HotSpot also understands the length of time an object has been around, and can make semi-smart decisions based on that knowledge). I beleive Sun has appended the Hotspot performance engine in his recent version of jdk 1.3.So we don't have to install it separately.

ReSources

(Please share your ideas about this topic, Any comment,suggestion, Write me on deepaksri@yahoo.com).