Sciology = Science + Technology

Commonsense in Technology

Do you care about Garbage Collection ?

Posted by sureshkrishna on October 23, 2007

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

Advertisements

5 Responses to “Do you care about Garbage Collection ?”

  1. Nigel Cook said

    It is rather quite stunning how similar this article is to this one;

    http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html

    At the very least, can you mention your source(s)?

  2. It is indeed stunning, how i ended up having a similar title. Damn…

    I definitely got this notes from a book which i read about the Java performance tunning.
    At this time i do not remember the book. I will update the comments with the links and book.

  3. […] spaceHelp me with PermGen:OutOfMemoryExceptionAptana : Source code editor for js, jsp, html, cssDo you care about Garbage Collection ?Top 10 technologies for 2008 from Gartner « Is anyone doing Mashup IDEs on […]

  4. chailuecha said

    >>>>
    public void something() {
    for (int i =0; i<5;i++) {
    Customer customer = new Customer();
    customer.printName();
    }
    }
    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

    ================
    Some sources claim that explicitly nulling local variable is not
    necessary.

    http://www.javaspecialists.eu/archive/Issue060.html
    “In this case, the compiler is intelligent enough to work out the scope of the image object, and has dereferenced it before the next assignment, so allowing it to be reclaimed before the next image is created”

  5. Its a rather philosophical issue to set the references to NULL or NOT.
    I see valid points on both the sides. But i PERSONALLY prefer setting the references to null.
    Even though i am sure that this does not readily make it available for GC, but i would have set the contents of the objects to null.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: