Tuesday, December 6, 2011

How the Common Language Runtime Performs Garbage Collection.


  • The common language runtime uses the garbage collector to manage memory that reference types use
  • The garbage collector ensures that an object is destroyed exactly once, and only when it is no longer in use
  • Write a destructor (Visual C#) or Finalize method (Visual Basic) to tidy up and free resources used by an object
  • The garbage collector calls the destructor or Finalize method before it destroys the object
  • Do not place time-critical code in a destructor or Finalize method
  • Do not rely on the garbage collector to call destructors or Finalize methods in a specific sequence
  • Implement the IDisposable interface
Computers do not have infinite amounts of memory, so memory must be reclaimed when
a variable or an object no longer requires it. Value types are destroyed and their memory
reclaimed when they go out of scope. This process is handled by the code that the
compiler generates when you build an application, and happens in a very deterministic
manner. In contrast, the garbage collector, which is part of the CLR, reclaims the memory
that the reference types use. This behavior is much less deterministic and not controlled
directly by your code.

The Processes of Creating and Destroying an Object
You create an object by using the new (C#) or New (Visual Basic) operator.
The following code examples create a new instance of the TextBox class.

[Visual C#]
TextBox message = new TextBox(); // TextBox is a reference type

[Visual Basic]
Dim message As New TextBox() ' TextBox is a reference type

From the programmer’s point of view, the new operation is atomic, but underneath,
object creation is really a two-phase process:

1. The new operation allocates a block of raw memory from the heap. You have no
control over this phase of an object’s creation.
2. The new operation converts the block of raw memory to an object; it has to initialize
the object. You can control this phase by using a constructor.

After you have created an object, you can access its members, and you can make other
reference variables refer to the same object, as the following code examples show.

[Visual C#]
TextBox messageRef = message;

[Visual Basic]
Dim messageRef As TextBox = message

You can create as many references to the same object as your application requires. This
has an impact on the lifetime of an object. The CLR has to keep track of all these
references. If the message variable disappears by going out of scope, other variables that
refer to the same object, such as messageRef, might still exist. The lifetime of an object
cannot be tied to a particular reference variable. The CLR can only destroy an object and
reclaim its memory when all of the references to it have disappeared.
Like object creation, object destruction is also a two-phase process.

The two phases of object destruction exactly mirror the two phases of object creation:
1. The CLR optionally performs some custom processing to tidy up and free resources
that the object uses. You can control this phase by writing a destructor.
2. The CLR deallocates the memory that the object uses and returns it to the heap. You
have no control over this phase.

No comments:

Recent Posts