We Keep Coding

Using Dispose() method

Why I see "Hello" words many times when I add timer.Dispose() to my code in release mode. Without timer.Dispose() I see "Hello" once. Thanks.
using System.Threading;
namespace ConsoleApplication1
{
class Program
{
static void Method(object state)
{
Console.WriteLine(state);
GC.Collect();
}
static void Main()
{
var timer = new Timer(Method, "Hello", 0, 200);
Console.ReadLine();
timer.Dispose();
}
}
}

You see it once because the garbage collector has collected the timer object.
Since there are no more references to it that is considered "live" the garbage collector is free to do so.
In release mode, and when no debugger is attached, the JITter builds up knowledge of where local variables are used in a method. Once a variable is no longer used, it is no longer considered to be a root if the method is currently executing below that point. As such, the garbage collector can collect the timer object. However, before it can do so it must finalize the object, which destroys the underlying timer object and stops it from executing.
In debug builds, the scope of all local variables are artificially extended to be the entire method, so that if you place a breakpoint in the method you can inspect variables, even if the program would no longer actually require that variable to exist.
When you added the call to dispose, you extended the lifetime of the variable, and thus prevented the garbage collector from collecting your timer object.
Since you provoke a garbage collection in the timer event handler method, you effectively destroy the timer yourself in this case. When you extended the lifetime of the variable by adding in the call to Dispose, the garbage collector still runs as part of your timer event handler, but it cannot yet collect the timer, so it keeps running.
The answer left here by Hans Passant describes this much better than my meager attempt above:
Understanding Garbage Collection in .NET.

I suspect it's because GC.Collect will not collect the timer object when it's still referenced below the current line of code.
timer.Dispose(); is acting like GC.KeepAlive(timer); in this instance.
If you remove both the Dispose and the GC.Collect(), you will get a few "Hello"s, and then the GC will decide to collect by itself, and you'll get no more.

Using floating curly braces to free variables early in C#

C# variables are instantiated where the type is declared (eg string s;) and freed at the closing brace of the current scope:
// Operates with Q memory
void FantasyMethod() {
var o = new BigObject();
{
var temp = new BigObject();
Populate(temp); // Populates o1 with N megabytes of data
o = PerformSomeOperationsOn(temp); // Returns a BigObject of size M (M is close to N)
// Currently, M+N memory is occupied, we have Q-M-N free
}
// Let's tell the garbage collector to catch up
GC.Collect();
GC.WaitForPendingFinalizers();
// Currently, M memory is occupied
DoUsefulStuffWith(o); // This method can only work if at least Q-M-N/2 memory is free
}
One benefit of this is that I can free large variables before the function returns. In the above (trivial) block, I have husbanded my limited available memory by disposing a large variable as soon as it is no longer needed.
Is the above correct?
Is doing this a good idea (I am interested in arguments for and against, not personal opinion or preference)? Would extracting the naked brace block as a method use memory less efficiently? What if I don't want to make a new method for readability reasons?

One benefit of this is that I can free large variables before the function returns.
No. C# isn't C++, objects don't have destructors, and you are not guaranteed that an object will be reclaimed the moment it leaves its declaring scope and no valid references to it exist.
If you need that level of predictability then you shouldn't be using a managed language, period. Techniques do exist which can help to alleviate memory pressure in C#, but they are not often needed and you will never get the level of control that a language like C or C++ will give you.
Per your edit:
GC.Collect will attempt to run a GC pass, it doesn't guarantee it. GC.WaitForPendingFinalizers blocks until all objects which have been marked for finalization have run their finalizers.
If an object implements a finalizer and has not disabled finalization by calling SuppressFinalize, the object is placed in a list of objects that are marked as ready for finalization. The garbage collector calls the Finalize methods for the objects in this list and removes the entries from the list. This method blocks until all finalizers have run to completion.

Your presumptions aren't entirely correct. Unlike C++ the objects aren't immediately destroyed (or if we want to be pedantic, have the destructor called) when they are out of scope. All that can be guaranteed is that if a GC sweep occurs while there are absolutely no references pointing to the objects instantiated within the closed scope then the object would be collected.
And even if you don't enclose the use of an object within an explicit scope the compiler already has enough information to 'know' that the object isn't being used/referenced anyway so you won't be doing it any favours.

It is incorrect, assuming BigObject is not a value type. If BigObject is a class then it will always exist on the managed heap and will not be deterministically disposed of after it falls out of scope. The GC runs in another thread and you cannot predict when it will do a collection.

I have never heard that placing a variable inside of a block would free the variable. Also what do you mean by freeing? Memory is managed by the garbage collector and it will determine when to free memory.
If the "variable" is holding a resource then it should implement IDisposable; http://msdn.microsoft.com/en-us/library/system.idisposable.aspx) and your could should be:
using (var b = new DisposableObject())
{
...
}

What is the correct way to free memory in C#

I have a timer in C# which executes some code inside it's method. Inside the code I'm using several temporary objects.
If I have something like Foo o = new Foo(); inside the method, does that mean that each time the timer ticks, I'm creating a new object and a new reference to that object?
If I have string foo = null and then I just put something temporal in foo, is it the same as above?
Does the garbage collector ever delete the object and the reference or objects are continually created and stay in memory?
If I just declare Foo o; and not point it to any instance, isn't that disposed when the method ends?
If I want to ensure that everything is deleted, what is the best way of doing it:
with the using statement inside the method
by calling dispose method at the end
by putting Foo o; outside the timer's method and just make the assignment o = new Foo() inside, so then the pointer to the object is deleted after the method ends, the garbage collector will delete the object.

1.If I have something like Foo o = new Foo(); inside the method, does that
mean that each time the timer ticks,
I'm creating a new object and a new
reference to that object?
Yes.
2.If I have string foo = null and then I just put something temporal in foo,
is it the same as above?
If you are asking if the behavior is the same then yes.
3.Does the garbage collector ever delete the object and the reference or
objects are continually created and
stay in memory?
The memory used by those objects is most certainly collected after the references are deemed to be unused.
4.If I just declare Foo o; and not point it to any instance, isn't that
disposed when the method ends?
No, since no object was created then there is no object to collect (dispose is not the right word).
5.If I want to ensure that everything is deleted, what is the best way of
doing it
If the object's class implements IDisposable then you certainly want to greedily call Dispose as soon as possible. The using keyword makes this easier because it calls Dispose automatically in an exception-safe way.
Other than that there really is nothing else you need to do except to stop using the object. If the reference is a local variable then when it goes out of scope it will be eligible for collection.1 If it is a class level variable then you may need to assign null to it to make it eligible before the containing class is eligible.
1This is technically incorrect (or at least a little misleading). An object can be eligible for collection long before it goes out of scope. The CLR is optimized to collect memory when it detects that a reference is no longer used. In extreme cases the CLR can collect an object even while one of its methods is still executing!
Update:
Here is an example that demonstrates that the GC will collect objects even though they may still be in-scope. You have to compile a Release build and run this outside of the debugger.
static void Main(string[] args)
{
Console.WriteLine("Before allocation");
var bo = new BigObject();
Console.WriteLine("After allocation");
bo.SomeMethod();
Console.ReadLine();
// The object is technically in-scope here which means it must still be rooted.
}
private class BigObject
{
private byte[] LotsOfMemory = new byte[Int32.MaxValue / 4];
public BigObject()
{
Console.WriteLine("BigObject()");
}
~BigObject()
{
Console.WriteLine("~BigObject()");
}
public void SomeMethod()
{
Console.WriteLine("Begin SomeMethod");
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("End SomeMethod");
}
}
On my machine the finalizer is run while SomeMethod is still executing!

The .NET garbage collector takes care of all this for you.
It is able to determine when objects are no longer referenced and will (eventually) free the memory that had been allocated to them.

Objects are eligable for garbage collection once they go out of scope become unreachable (thanks ben!). The memory won't be freed unless the garbage collector believes you are running out of memory.
For managed resources, the garbage collector will know when this is, and you don't need to do anything.
For unmanaged resources (such as connections to databases or opened files) the garbage collector has no way of knowing how much memory they are consuming, and that is why you need to free them manually (using dispose, or much better still the using block)
If objects are not being freed, either you have plenty of memory left and there is no need, or you are maintaining a reference to them in your application, and therefore the garbage collector will not free them (in case you actually use this reference you maintained)

Let's answer your questions one by one.
Yes, you make a new object whenever this statement is executed, however, it goes "out of scope" when you exit the method and it is eligible for garbage collection.
Well this would be the same as #1, except that you've used a string type. A string type is immutable and you get a new object every time you make an assignment.
Yes the garbage collector collects the out of scope objects, unless you assign the object to a variable with a large scope such as class variable.
Yes.
The using statement only applies to objects that implement the IDisposable interface. If that is the case, by all means using is best for objects within a method's scope. Don't put Foo o at a larger scope unless you have a good reason to do so. It is best to limit the scope of any variable to the smallest scope that makes sense.

Here's a quick overview:
Once references are gone, your object will likely be garbage collected.
You can only count on statistical collection that keeps your heap size normal provided all references to garbage are really gone. In other words, there is no guarantee a specific object will ever be garbage collected.
It follows that your finalizer will also never be guaranteed to be called. Avoid finalizers.
Two common sources of leaks:
Event handlers and delegates are references. If you subscribe to an event of an object, you are referencing to it. If you have a delegate to an object's method, you are referencing it.
Unmanaged resources, by definition, are not automatically collected. This is what the IDisposable pattern is for.
Finally, if you want a reference that does not prevent the object from getting collected, look into WeakReference.
One last thing: If you declare Foo foo; without assigning it you don't have to worry - nothing is leaked. If Foo is a reference type, nothing was created. If Foo is a value type, it is allocated on the stack and thus will automatically be cleaned up.

Yes
What do you mean by the same? It will be re-executed every time the method is run.
Yes, the .Net garbage collector uses an algorithm that starts with any global/in-scope variables, traverses them while following any reference it finds recursively, and deletes any object in memory deemed to be unreachable. see here for more detail on Garbage Collection
Yes, the memory from all variables declared in a method is released when the method exits as they are all unreachable. In addition, any variables that are declared but never used will be optimized out by the compiler, so in reality your Foo variable will never ever take up memory.
the using statement simply calls dispose on an IDisposable object when it exits, so this is equivalent to your second bullet point. Both will indicate that you are done with the object and tell the GC that you are ready to let go of it. Overwriting the only reference to the object will have a similar effect.

The garbage collector will come around and clean up anything that no longer has references to it. Unless you have unmanaged resources inside Foo, calling Dispose or using a using statement on it won't really help you much.
I'm fairly sure this applies, since it was still in C#. But, I took a game design course using XNA and we spent some time talking about the garbage collector for C#. Garbage collecting is expensive, since you have to check if you have any references to the object you want to collect. So, the GC tries to put this off as long as possible. So, as long as you weren't running out of physical memory when your program went to 700MB, it might just be the GC being lazy and not worrying about it yet.
But, if you just use Foo o outside the loop and create a o = new Foo() each time around, it should all work out fine.

As Brian points out the GC can collect anything that is unreachable including objects that are still in scope and even while instance methods of those objects are still executing. consider the following code:
class foo
{
static int liveFooInstances;
public foo()
{
Interlocked.Increment(ref foo.liveFooInstances);
}
public void TestMethod()
{
Console.WriteLine("entering method");
while (Interlocked.CompareExchange(ref foo.liveFooInstances, 1, 1) == 1)
{
Console.WriteLine("running GC.Collect");
GC.Collect();
GC.WaitForPendingFinalizers();
}
Console.WriteLine("exiting method");
}
~foo()
{
Console.WriteLine("in ~foo");
Interlocked.Decrement(ref foo.liveFooInstances);
}
}
class Program
{
static void Main(string[] args)
{
foo aFoo = new foo();
aFoo.TestMethod();
//Console.WriteLine(aFoo.ToString()); // if this line is uncommented TestMethod will never return
}
}
if run with a debug build, with the debugger attached, or with the specified line uncommented TestMethod will never return. But running without a debugger attached TestMethod will return.

When are method variables, accessible in an anonymous method, garbage collected?

For instance is it necessary to add a Timer instance to a list as I am doing here to prevent the Timer being garbage collected? Tyically if the callback was not anonymous the aswer is yes, but since it is anonymous i imagine the variables in the method block which are accessible in the anonymous method block will only be garbage collected when the anonymous method completes? In which case no need to save ref as I am doing..:
private static List<Timer> timers = new List<Timer>();
public static void RunCallbackAfter(Action callback, int secondsToWait)
{
Timer t = null;
t = new Timer(new TimerCallback(delegate(object state)
{
SomeThread.BeginInvoke(callback);
timers.Remove(t);
}), null, secondsToWait*1000, Timeout.Infinite);
timers.Add(t);
}

The objects referred to by the captured variables in the anonymous method will not be eligible for garbage collection until the delegate created by the anonymous method is eligible for garbage collection.
However, if it's only the Timer which has a reference to the delegate, and nothing else has a reference to the timer, then I suspect both would be eligible for garbage collection, assuming this is indeed the kind of timer which you need to keep a reference to. (I seem to remember that some timers do require this and some don't. I can't remember which is which.)
Also, if you removed the timers.Remove(t) call from within the anonymous method then it wouldn't be capturing t in the first place. It's only captured variables which have prolonged lifetimes... not every variable in the method which contains the anonymous method.

In general, anonymous functions in C# will keep any local variables that they reference alive until the anon function itself is destroyed. Naturally, removing the remove call in this case would remove the reference, meaning the variable would no longer be kept alive by the callback.
However, this here forms a circular reference; unless there's an outside reference the timer and callback could be destroyed simultaneously. I'm not sure if starting a timer counts as an external reference keeping it alive in C#, so I can't answer your question fully, though. If a started timer is treated as having an external reference, then that alone would keep both the timer and callback alive.

No. You don't need to stash away your timer. It would normally be garbage collected, since it is only referenced by your delegate. However, I believe that the Timer constructor places a reference with the underlying runtime, so you should be fine.
Raymond Chen probably has something to say in his blog post: The implementation of anonymous methods in C# and its consequences (part 1)
Your Timer variable t will stay accessible as long as there is a reference to your anonymous method. Your anonymous method will stay referenced until the event has fired. At least that long.
According to Raymond Chen, the c# compiler turns your code into something else, with the context of your method (including the this pointer of the enclosing object) all wrapped up in its own little compiler generated class. So it seems the anonymous method (or delegate) itself contains the reference to the timer.
Oh, and everyone else in this thread are correct: I just blurted out some stuff (and learned about how the C# compiler handles anonymous methods at the same time).
So yes, you have a circular reference. But I'm pretty sure creating a timer should hook that up somewhere in the runtime / windows. Let's have a check.
Using Reflector, you can follow the trail from System.Timer.Timer() through to TimerBase, which has an extern method AddTimerNative. I'm not sure how to peek into that, but I'm going to bet it registers your timer with the OS.
Conclusion: Your timer will not go out of scope, as it will be referenced by the OS until it fires.

In the Dispose(bool) method implementation, Shouldn't one set members to null?

None of the guides/notes/articles that discuss IDisposable pattern suggest that one should set the internal members to null in the Dispose(bool) method (especially if they are memory hogging beasts).
I've come to realize the importance of it while debugging an internal benchmark tool. What used to happen was that, there was this buffer that contained a big array inside it. We used to use a static buffer for the whole benchmark program. Once we're done with the buffer, there was no way we could release this internal array, neither could we make this buffer releasable (as it was static).
So, I believe that, after Dispose() is called, the class should do everything it can so that it releases all the resources it is using and make them available again, even if the object being disposed itself is not collected back by GC, and not setting members to null, thereby, not allowing the internal objects to be collected by the GC implies that the Dispose implementation is not perfect.
What's your opinion on this ?

Releasing any additional references during Dispose is certainly something I try to do, for two reasons:
it allows the inner objects to be garbage collected even if the disposed object is still in scope
if the inner objects are disposable, it means we only dispose them once even if Dispose() is called repeatedly on the outer object
For example, I tend to use things like:
if(someDisposableObject != null)
{
someDisposableObject.Dispose();
someDisposableObject = null;
}
(for non-disposable, just set to null)
someNonDisposableObject = null; // etc
You might also want to set any events to null:
someEventHandler = null;
This can help minimise the impact if the caller can't fully release their reference (or simply forgets) at the moment. While you should try to release the outer object (for GC), it is relatively easy to accidentally extend the life of the object, for example via a captured variable (anonymous method/lambda), an event, etc.
If you have a finalizer, then during the GC process there is no benefit doing this, and you shouldn't really call methods on external objects (even Dispose()) - so in short: don't do any of this during a GC sweep.

Maybe I'm missing your point, but once your object is disposed, the root or 'sub-root' it represented relative to it's members has been detached. It seems like you are thinking of garbage collection like a ref count system (which can be done, but ... usually isn't).
Instead, think of it as a many-rooted tree, where every object has branches for what it links to. At the end of the day the 'final roots' are statics and anything instantiated from a 'main' loop.
When the garbage collector runs, the easiest way to think about what it does is to consider that it will walk the list of 'real roots' and apply a 'color' to everything it can 'reach'.
Now, assumed the collector has access to 'everything', whether it was rooted or not. Anything not colored can be cleaned up.
Getting back to your original question, when your object is disposed, one assumes (or at least hopes) that no one references it anymore. If this is the case, it is no longer rooted, and so it will not contribute to 'coloring' anything it touches.
Long story longer - if nulling out members in a Dispose routine is fixing something - I would be you have a different, and real, problem that someone is holding a link to your disposed object, and keeping it 'reachable' when it should not be.
I apologize for what may be the most over-quote-filled message I've ever written, but I'm sort of abusing standard terms.

Well, generally, it's not going to make a difference. The only place where it will make a difference is when you have a reference to an object on the Large Object Heap, the behavior of which you have seen already).
There is a good article on the LOH which goes into this in more detail here:
http://msdn.microsoft.com/en-us/magazine/cc534993.aspx