helperD=null; whenevr i finish using an instatiated object or no need

Thanks

It is good habit. The sooner you release all references to an object, the sooner the GC will be able to collect it.

When a function exits, all locally declared variables are effectively nulled (they are owned by the stack frame itself, which no longer counts as a GC root). So even if you forget to null local variables, they will eventually get cleaned up. The catch is that if a GC cycle runs during that window of time after the variable is no longer needed, but before the stack frame unwinds (such as if you are continuing to do work in the rest of the method), then the object will not be seen as "collectible" by the GC. This means that it will be promoted to the next higher garbage generation, which can be a bad thing if it happens a lot.

Now when it comes to class member fields, then yes you should always be nulling them once they are no longer needed. Otherwise, they will remain in the GC heap at least until the owning class itself gets collected (even longer if the objects have a Finalizer).

You can get some fabulous information on this topic from Rico Mariani's weblog at http://blogs.msdn.com/ricom/ (he calls this particular phenomenon "mid-life crisis").

HTH

The catch is that if a GC cycle runs during that window of time after the variable is no longer needed, but before the stack frame unwinds (such as if you are continuing to do work in the rest of the method), then the object will not be seen as "collectible" by the GC.

Yes it will. As long as the variable isn't used any more in that method (and no other references exist) the object can be collected.

Hi R.Tutus I have a blog entry that describes when to set variables to null: http://blogs.msdn.com/clyon/archive/2004/12/01/273144.aspx Mattias is correct; in general the JIT and GC are smart enough to know when the last time an object is referenced and make it eligible for collection without the need for setting the reference to null. -Chris

Ah, thats good to know. My understanding was that this particular optimization wasn't in place yet, but something that was desired by the CLR team in a future version. It made sense that the GC would consider any local vars contained in any active part of the call stack as potential roots - but your blog entry also makes a lot of sense too (the optimization only applying to Release builds).