Do you care about Garbage Collection ?

Recently there have been few instances our RCP application crashed with the OutOfMemory exception and it took lot of time to look reasons behind the crash. An easy solution is to increase the PermGen from 64mb (default) to 256mb (recommended). Well, this works for the application and i am happy. Since then, i explored few books and articles to look into the memory allocation, objects creation and garbage collection can effect the application and its memory needs.

Garbage Collection is the concept that its publicized as “JVM does automatic GC”. But in reality this does not seem to be as cool as it sounds. Developers should not completely relay on JVM to take care of your applications memory needs and garbage collection. A solid understanding on “How GC works” is essential to write robust and high-performance applications.

Its necessary to understand the complete life-cycle of an object and how it transforms its state from declaration till garbage collection. We will look into each of the state in detail.

• Created
• In Use
• Invisible
• Unreachable
• Collected
• Finalized
• Deallocated

Created: Creating the object makes many things to happen. Space is allocated for the Object. Object constructor is called. If at all there is a super class, it constructor is called. Instance variables are initialized. In the end its important to realize that the object construction does take time and this depends on the JVM implementation for sure.

In Use : Once an object has strong reference, its said to be In Use. It is normal for any object to be In Use state for relatively longer than any other states.

1. public class InUseClass {
2. static List someList = new ArrayList();
3. static void doSomething() {
4. Customer customer = new Customer();
5. somelist.add(customer);
6. }
7. public static void main(String[] args) {
8. doSomething();
9. }
10. }

In the above code you can see that the at the time doSometing() is executing, there are 2 instances of the Customer that’s holds on. One in the line 4 and one in the line 2. Once the doSomething() returns, there is only one instance that remain of Customer which is line from line #2. Which is a reference of the Customer object in the List. Thus you can imagine that there would be lots of references that remain strongly referenced even after they are used up.

Invisible : When an object is no longer strongly referenced but references still exists, its said to be in Invisible state. Its not necessary that all objects go via this state. In the following code snippet you can see that the strong object references are lost once the something() method is returned. In other words, they go out of scope once the method is returned.

1. public void something() {
2. for (int i =0; i<5;i++) {
3. Customer customer = new Customer();
4. customer.printName();
5. }
6. }

This scenario is dangerous and one of the main causes for the memory leaks. In this code block the references become invisible and its recommended to make the references null explicitly.

Unreachable: An object is in Unreachable state when there are no strong references and it will be marked for the collection. Of course “marked for collection” does not mean that JVM does the GC immediately. JVM has all its freedom to delay till memory is required by application.

Collected: When an object is unreachable the JVM readies it for the finalization. If an instance has the finalize method then it is marked and if the instance does not have any finalize method, it will move directly to Finalized state. Its very important to note that the when an instance has the finalize method, the deallocation process is delayed.

Finalized: Once the finalize method is run, if the object is still unreachable, its in the Finalized state. A finalized object is waiting for the deallocation. Its certain that the object’s life is prolonged when the finalize method is attached to the object. Also its not recommended to attach the finalize method for short-lived classes.

Deallocation: After all the above steps if the object is still unreachable, then the object is marked for the deallocation state. Its not sure when exactly the JVM deallocates, but this is dependent on the implementation of GC algorithms.

In the end, GC is not really what many of us perceive. An extra care must be taken to carefully write the applications with a special check on the object references and freeing the memory when ever possible.

“Nothing comes for free and so is GC”.