Java Garbage Collection: How it works, How to control it

Java has Garbage Collection. Good thing, yes! But, say with me:

The Garbage Collector deallocates all objects with zero references when it wants!!

Two troubles:

• Objects with zero references: typically a Java code looks like:
  

  public void doSomething() {
      Configuration c = new Configuration("test.conf");
      long limit = c.getLimit();    
  
      for(long i = 0; i≤limit ; i++) {
         String s = new String(i);
         System.out.println(s);
      }
  }
  

  
  The Configuration instance lives until the method's end. We can write:
  

  public void doSomething() {
      Configuration c = new Configuration("test.conf");
      long limit = c.getLimit();
      c = null;     // good! now c has 0 reference!    
  
      for(long i = 0; i≤limit ; i++) {
         String s = new String(i);
         System.out.println(s);
      }
  }
  



• GC deallocates them when it wants: it seems that the String instances will be cleaned when they go out of scope, but it isn't!!.
  The String instances are in a particular state called Invisible State.
  The GC cleans all the object that go out of scope only when the method doSomething() returns!!
  Simply, manually set the reference to null:
  

  public void doSomething() {
      Configuration c = new Configuration("test.conf");
      long limit = c.getLimit();
      c = null;     // good! now c has 0 reference!    
  
      for(long i = 0; i≤limit ; i++) {
         String s = new String(i);
         System.out.println(s);
         s = null;    // good! now s has 0 reference!
      }
  }
  

  
  Now all our Object are only eligible for cleaning.
  You cannot force garbage collection, just suggest it! You can suggest GC with System.gc(), but this does not guarantee when it will happen.
  

Interesting links: Sun's Truth About Garbage Collection,

Memory Leaks in C++: important rules

This topic seems obvious, but it isn't!! Many memory leaks errors derive from these errors!!

So, there are some rules you must consider:

1. In polymorphic base class you must declare destructors virtual. If you don't, the results are undefined. Typically, the derived part of the object is never destroyed (memory leak). The same analysis applies to any class lacking a virtual destructor, including std::string and all the STL container types. You do never inherit from a standard container of from any other class with a non-virtual destructor!!
2. Destructors should never emit exception. This situation can arise the problem of simultaneously active exceptions: the result is undefined. There are three primary ways to avoid the trouble:
• Terminate the program calling abort
• Swallow the exception (but it suppresses that something failed)
• Provide a regular function that gives the opportunity to react to problems that may arise (i.e., storing the result of destructor in a boolean variable)
  
3. Have assignment operators return a reference to *this
4. To make sure that a resource is always released, we need to put that resource inside an object (a resource manager) whose destructor will automatically release the resource. This idea is often called Resource Acquisition Is Initialization (RAII).
   
5. A smart pointer SP is a wrapper for a resource (i.e., std::auto_ptr). It's destructor automatically calls delete on what it points to. Attention: copying auto_ptr set it to null and the copying pointer assumes sole ownership of the resource!
   
6. A reference-counting smart pointer RCSP (i.e., std::tr1::shared_ptr) is a smart pointer that keeps track of how many objects point to a particular resource and automatically deletes the resource when nobody is pointing to it any longer. It also supports custom deleters: this prevents the cross-DLL problem and can be used to automatically unlock mutexes.
   
7. SP and RCSP use delete, not delete[]. For arrays, look to Boost classes: boost::scoped_array and boost::shared_array.
8. Initialize SPs in standalone statements (not in complex operations). Failure to do this can lead to subtle resource leaks when eceptions are thrown
9. By default, C++ passes object by value:
   

   void viewImage(Image i) {
    i.view();
   }
   

   This is an expensive operation: function parameters are copies of the actual arguments! To bypass all related contructions and destructions, you have to pass by reference-to-const:
   

   void viewImage(const Image& i) {
    i.view();
   }
   

   Passing parameters by reference also avoids the slicing problem (when you don't use virtual function in polymorphic classes).
   
10. It's instead more efficient to pass by value than by reference the following items:
• built-in types (e.g. an int)
• iterators in STL
• function objects in STL
  
11. Prefer this way to write functions that return a new object:
    

    inline const Image createImage(const Bitmap& bmp) {
     return Image(bmp.getName(), bmp.getData());
    }
    

    It's faster than you expected and prevents many errors.
    


12. Remember that you incur:
• the cost of construction when control reaches the variable's definition
• the cost of destruction when variable goes out of scope
You should postpone the definition until you have initialization arguments for it.

13. In loops:
    
• it's more efficient define variables outside the loop and make an assignment to it on each loop iteration
• it's more readable define variables inside the loop. Unless you're dealing with a performance-sensitive part of your code, you should using this approach.
14. Don't inline everything! Consider the rule of 80-20: a typical program spends 80% of its time executing only 20% of its code. You goal as a software developer is to identify the 20% of your code.
    

This work comes from the Scott Meyers's book "Effective C++ - Third Edition"
Very interesting the George Belotsky's article.