Develop Reference

When is SystemTimers.Timer considered garbageif no reference is saved?

I am very curious to know when a System.Timers.Timer is considered garbage and therefor collected by the Garbage Collector if I do not store a reference to it, but it is Enabled.
But at what point is my Timer considered garbage?
Consider the following code:
public void TriggerUpdateStatus() {
toolStripStatusLabel1.Text = "*";
new Timer() {
Interval = 1000,
Enabled = true
}.Elapsed += new ElapsedEventHandler(
(object sender, ElapsedEventArgs args) => {
toolStripStatusLabel1.Text = "";
Timer t = ((System.Timers.Timer) sender);
t.Stop();
t.Dispose();//Is this needed?
});
}
This block of code will run once every two seconds when my code triggers an update, it then adds a star character in the bottom corner of my form, indicating that the connection is alive and well. I create a Timer with no reference that will simply remove the star again after a second, stop it self and dispose of itself.

No, t.Dispose(), isn't necessary, it will be collected regardless.
The question itself seems to convey a deep misunderstanding about how the GC and Dispose work (I stress the word seems). The GC has absolutely no idea what Dispose does and couldn`t care less. That an object is disposed or not doesn't come in to play as to wether that particular object is elegible for collection; these are two completely orthogonal concepts.
Dispose is there as a mechanism to release unmanaged resources, it has nothing to do with how the garbage collector works.
If that is clear, then Dispose, although polite, isn't even strictly necessary; Dispose (or the needed part of it) will run anyway when the timer is eventually collected (the object is unreachable and short lived so it shouldn't take too long), put in the finalizer queue and finalized in some undetermined future; it is polite and recommended to dispose in order to deterministically release all unmanaged resources associated with the object instead of relying on whenever the finalizer queue decides to run, which brings up the next point:
Why are you newing up a Timer every two seconds and then disposing it immediately? Wouldn't it be much easier to have one single timer and reset it every time?

c# my destructor isn't being called?

I have this simple code and trying to call the destructor but I can't call it :(
I know that GarbageCollector runs when it's necessary, so I used GC.WaitForPendingFinalizers(); but it didn't work either.
Here is my code:
class Program
{
static void Main(string[] args)
{
Calculator calculator = new Calculator();
Console.WriteLine("{0} / {1} = {2}", 120, 15, calculator.Divide(120, 15)
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("Program finishing");
}
}
class Calculator
{
// Constructor
public Calculator()
{
Console.WriteLine("Calculator being created");
}
// Public Divide method
public int Divide(int first, int second)
{
return first / second;
}
// Destructor
~Calculator()
{
Console.WriteLine("Destructor is called");
}
}
And here is my output:
Calculator being created
120 / 15 = 8
Program finishing
What am I doing wrong? Why can't I see "Destructor is called" ?

The lifetime of a local variable is the lifetime of the activation of control within the local variable scope that declares it. So your local is alive until the end of main. That alone is sufficient to explain why it is not collected, but there are subtleties here that we should explore in more depth.
The lifetime may be extended by a variety of mechanisms, including capturing outer variables by a lambda, iterator blocks, asynchronous methods, and so on.
The lifetime is permitted to be shortened in cases where the jitter can prove that doing so has no effect on the single-threaded flow of control. (You can use KeepAlive to ensure this shortening does not happen in cases where you must avoid it.)
In your case, the runtime is permitted to notice that the local is never read from again, mark it as dead early, and thereby orphaning the reference to the object, which would then be collected and finalized. It is not required to do so, and apparently, in your case, does not.
As another answer correctly notes: the GC will deliberately suppress this optimization if it detects that a debugger is running, because it is a bad user experience for an object to be collected while you are examining a variable containing a reference to it in the debugger!
Let's consider the implications of my statements about shortened lifetimes, because I think you may not have fully grasped those implications.
The runtime is permitted to notice that the ctor never accesses this.
The runtime is permitted to notice that divide never accesses this.
The runtime is permitted to notice that therefore the local is never actually read from and used
Therefore the object is permitted to be never rooted in the GC at any point in its lifetime.
Which means that the garbage collector is permitted to run the finalizer before the constructor.
The GC and finalizer runs on their own threads, remember; the operating system could suspend the main thread and switch to the gc and finalizer threads at any point, including after the allocator runs but before control passes to the constructor.
Absolutely crazy things are permitted to happen in scenarios like the one you wrote; the finalizer not running is the least of your problems! It is when it could run that is scary.
If that fact was not immediately clear to you, then you have no business writing a finalizer. Writing a correct finalizer is one of the hardest things to do in C#. If you are not an expert on all the fine details of the CLR garbage collector semantics, you should not be writing a finalizer.
For more thoughts on how writing a finalizer is difficult, see my series of articles on the subject, which begins here:
https://ericlippert.com/2015/05/18/when-everything-you-know-is-wrong-part-one/

If you run a program with the debugger attached it changes the behavior of the lifetime of objects.
Without the debugger a object becomes ellagable for collection as soon as the last use of the object has been passed in the code. With the debugger attached the lifetime of all objects get extended to the entire time the object is in scope, this is done so you can view the object in the Watch window of the debugger and not have the object collected out from under you.
You must either run your program in release mode without the debugger attached or set calculator to null before you call GC.Collect() to be able to have the object be eligible for garbage collection and have it's finalizer run.

I would not recommend to really on destructors .net
anyway in your case GC don't think your object is garbage at the moment you calling GS because you have alive link in your stack calculator which is point to object in heap
so you can try to modify this code
main(){
DoCalculations();
//at this point object calculator is garbage (because it was allocated in stack)
GC.Collect();
}
DoCalculations(){
Calculator calculator = new Calculator(); // object allocated
calcualtor.doSomething(); //link alive
}

Declaring and disposing a local variable in a function/method in .Net

Until recently it never really bothered me as to how to best declare and dispose of a local variable but I thought I'd ask once and for all and get some feedback as it's starting to bug me more and more these days.
When creating a function/method that creates a local object, which method is best to create and dispose of the object.
For simplicity sake, assume that the method of the object being called will never generate an exception i.e. ConvertThisToString
private string myFirstFunction()
{
MyDataType myObject = null;
try
{
myObject = new MyDataType();
return myOjbect.ConvertThisToString();
}
finally
{
myObject = null;
}
}
or
private string mySecondFunction()
{
MyDataType myObject = new MyDataType();
return myOjbect.ConvertThisToString();
}
Are both functions ok and is it just about coding preferences or is there one method that's better than the other? Why?
My opinion is that one always requires the try/catch in order to nullify the object, which might be an overkill of try/catch for nullifying's sake, while the other method doesn't call any explicit way to destroy the object, which might be to reliant on .NET GC to release it from memory.
Should I be using the "using" statement instead?
Well, this is probably an incorrect statement. Is a local object immediately destroyed and disposed of when leaving a function or will it be cleared at a later stage by the GC management or other.
Thanks for feedback.
Thierry
UPDATED:
Removed the catch block as it caused confusion in my question. Should haven't been there in the first place since I did say, no error would ever occur.

That's very wrong.
Don't swallow exceptions.
Assigning a variable to null at the end of its scope will not help the GC at all.
If your object actually has expensive resources, it should implement IDisposable (correctly!), and you should dispose it using a using statement (but only when you're finished with it!)

You don't need to assign to null. When the object leaves scope, it will automatically be eligible for GC. There is no need to do anything special.
Basically, just write the second, simple version.
Should I be using the "using" statement instead?
If your object is wrapping resources (not memory allocated via new ..., but native resources) and implements IDisposable, then yes, you should use the using statement to guarantee those are cleaned up.
Is a local object immediately destroyed and disposed of when leaving a function or will it be cleared at a later stage by the GC management or other.
It will become eligible to be collected. At some point in the future, the GC will clean it up, but the time when this happens in indeterminant.

The best approach here is the Using statement.
something like this:
private string myFirstFunction()
{
using(MyDataType myObject = new MyDataType())
{
return myObject.ConvertThisToString();
}
}
this will dispose the object after execution.

As with almost everything, it all depends on what object you are using. If the object you are creating implements IDisposable then you would be best served to place in a using (typically). Outside of that most objects will get cleaned up by the garbage collector. IF you are the producer of a class that accesses COM objects then as the producer you should have provided a away for a proper cleanup, e.g. implement the IDisposable interface and handle the Dispose() correctly. As others have commented swallowing exceptions or even try/catching EVERY method doesn't seem like a reasonable or good idea. If a call you are making has the potential of throwing an exception and you have unmanaged or leaky objects then you should handle via a try/finally or a using (again, if appropriate).

You don't need to use a try/catch/finally to set a variable to null. The .NET GC will clear up any unreferenced classes when a method ends in it's own time.
If you are doing something really intensive (more so than your sample shows) then you can set the variable reference to null as a pointer to the GC that this is no longer referenced. This will only make a difference to your program if you are doing something which ends up marking the variable reference for Gen2 collection and then you do more stuff which prevents the GC collecting your variable (because the scope has not been left - in this case the method).
This is a bit of an extreme case as the .NET GC is designed to remove this aspect of programming from your daily concern, and regardless, it should get cleared up when the scope ends - it might just a bit longer.
You use 'using' if the referenced object implements IDisposable, and you do this typically to release unmanaged resources - though there may be other reasons why a class implements this interface.
Your first method is total overkill... it should just be as described in MySecondFunction(), and just don't swallow exceptions (I'm referring to the empty catch block) like that - because it leads to buggy, unmaintanable code! :)

.NET 4.5 Async/Await and the Garbage Collector

I am wondering about the behavior of async/await in relation to garbage collecting local variables. In the following example, I have allocated a sizable portion of memory and go into a significant delay. As seen in the code, Buffer is not used after the await. Will it get garbage collected while waiting, or will the memory be occupied for the duration of the function?
/// <summary>
/// How does async/await behave in relation to managed memory?
/// </summary>
public async Task<bool> AllocateMemoryAndWaitForAWhile() {
// Allocate a sizable amount of memory.
var Buffer = new byte[32 * 1024 * 1024];
// Show the length of the buffer (to avoid optimization removal).
System.Console.WriteLine(Buffer.Length);
// Await one minute for no apparent reason.
await Task.Delay(60000);
// Did 'Buffer' get freed by the garabage collector while waiting?
return true;
}

Will it get garbage collected while waiting?
Maybe. The garbage collector is permitted to do so but not required to.
Will the memory be occupied for the duration of the function?
Maybe. The garbage collector is permitted to do so but not required to.
Basically, if the garbage collector can know that the buffer will never be touched again then it can free it at any time. But the GC is never required to free anything on any particular schedule.
If you are particularly concerned, you can always set the local to null, but I would not bother doing so unless you demonstrably had a problem. Alternatively, you could extract the code that manipulates the buffer into its own non-async method and call it synchronously from the async method; then the local becomes just an ordinary local of an ordinary method.
The await is realized as a return, so the local will go out of scope and its lifetime will be over; the array will then be collected on the next collection, which is required to be during the Delay, right?
No, none of those claims are true.
First, an await is only a return if the task is not completed; now, it is of course nigh impossible that Delay will be completed, so yes, this will return, but we cannot conclude in general that an await returns to the caller.
Second, the local only vanishes if it is actually realized in IL by the C# compiler as local in the temporary pool. The jitter will jit that as a stack slot or register, which vanishes when the activation for the method ends at the await. But the C# compiler is not required to do that!
It would seem strange to a person in the debugger to put a breakpoint after the Delay and see that the local has vanished, so the compiler might realize the local as a field in a compiler-generated class that is bound to the lifetime of the class generated for the state machine. In that case it is much less likely that the jitter will realize that this field is never read again, and therefore much less likely to throw it away early. (Though it is permitted to do so. And also the C# compiler is permitted to set the field to null on your behalf if it can prove that you're done using it. Again, this would be weird for the person in the debugger who suddenly sees their local change value for no apparant reason, but the compiler is permitted to generate any code whose single-threaded behaviour is correct.)
Third, nothing requires the garbage collector to collect anything on any particular schedule. This large array will be allocated on the large object heap, and that thing has its own collection schedule.
Fourth, nothing whatsoever requires there to be a collection of the large object heap in any given sixty second interval. That thing need never be collected if there is no memory pressure.

What Eric Lippert said is true: the C# compiler has quite a lot of leeway about what IL should it generate for the async method. So, if you're asking what does the specification say about this, then the answer is: the array may be eligible for collection during the wait, which means it may be collected.
But another question is what the compiler actually does. On my computer, the compiler generates Buffer as a field of generated state machine type. That field is set to the allocated array, and then it's never set again. That means the array will become eligible for collection when the state machine object does. And that object is referenced from the continuation delegate, so it won't become eligible for collection until after the wait completes. What this all means is that the array won't be eligible for collection during the wait, which means it won't be collected.
Some more notes:
The state machine object is actually a struct, but it's used though an interface it implements, so it behaves as a reference type for the purpose of garbage collection.
If you actually determine that the fact that the array won't be collected is a problem for you, it might be worth to set the local to null before the await. But in the vast majority of cases, you don't have to worry about this. I'm certainly not saying you should regularly set locals to null before await.
This is very much an implementation detail. It can change at any time and different versions of the compiler may behave differently.

Your code compiles (in my environment: VS2012, C# 5, .NET 4.5, Release mode) to include a struct that implements IAsyncStateMachine, and has the following field:
public byte[] <Buffer>5__1;
Thus, unless the JIT and/or GC are really clever, (see Eric Lippert's answer for more on that) it'd be reasonable to assume that the large byte[] will stay in scope until the async task is complete.

I'm pretty sure its collected, since await ends your current task and "continues with" another task,
so local vars should be cleaned when they are not used after the await.
BUT: What the compiler actually does could be something different, so I would not depend on such a behaviour.

There is an update on this topic with Rolsyn compiler.
Running following code in Visual Studio 2015 Update 3 in release configuration produces
True
False
So the locals are garbage collected.
private static async Task MethodAsync()
{
byte[] bytes = new byte[1024];
var wr = new WeakReference(bytes);
Console.WriteLine(wr.Target != null);
await Task.Delay(100);
FullGC();
Console.WriteLine(wr.Target != null);
await Task.Delay(100);
}
private static void FullGC()
{
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
}
Note, that if we modify MethodAsync to use local variable after await, then array buffer will not be garbage collected.
private static async Task MethodAsync()
{
byte[] bytes = new byte[1024];
var wr = new WeakReference(bytes);
Console.WriteLine(wr.Target != null);
await Task.Delay(100);
Console.WriteLine(bytes.Length);
FullGC();
Console.WriteLine(wr.Target != null);
await Task.Delay(100);
FullGC();
Console.WriteLine(wr.Target != null);
}
The output for this is
True
1024
True
True
The code samples are taken from this rolsyn issue.

Will it get garbage collected while waiting?
Nope.
will the memory be occupied for the duration of the function?
Yes.
Open your compiled assembly in Reflector. You'll see the compiler generated a private struct that inherits from IAsyncStateMachine, the local variables of your async method being a field of that struct. The data fields of the class/struct are never freed while the owning instance is still alive.

Form.ShowDialog() and dispose

If I have a method like this:
public void Show()
{
Form1 f = new Form1();
f.ShowDialog();
}
Do I still need to call dispose on the form even though it will go out of scope, which will be eligible for garbage collection.
From some testing, calling this Show() multiple times .. at some point it seems like the GC collects it since I can see the memory spiking then it goes down at some point in time.
From MSDN it seems to say you MUST call dispose when the form is not needed anymore.

What tends to happen is if the item has purely managed resources, calling dispose is not necessarily required, but is strongly advised because it makes disposal deterministic. It isn't always required (in a technical sense) because those managed resources would likely themselves now be eligible for GC, or there is actually nothing to dispose by default and it's an extensibility point.
For unmanaged resources, the Dispose Pattern advises implementing a finalizer, which will be called on GC. If types do not implement the finalizer and dispose is not called, then it is possible (well, very likely) that resources would be left unhandled. Finalizers are the last chance offered by the runtime for clearing your stuff up - they are also time-limited.
Note, that it does not make GC or managed memory reclamation deterministic, disposal is not delete from C++. A disposed item could be a long way away from actually being collected. However, in the managed world, you don't care about deterministic collection, only resource management - in other words, disposal.
That said, I always make sure I call Dispose or use a using statement if a type is disposable, regardless of whether it uses managed or unmanaged resources - it is the expected convention:
public void Show()
{
using (var f = new Form1())
{
f.ShowDialog();
} // Disposal, even on exceptions or nested return statements, occurs here.
}
Update:
After a discussion with Servy I feel I have to express this point as the reasoning behind my advice of disposing where possible. In the case of MemoryStream, it is clearly a disposable type, but actually does not dispose of anything currently.
Relying on this, however, is to rely on the implementation of MemoryStream. Were this to change to include an unmanaged resource, this would then mean that a reliance on MemoryStream not having anything to dispose becomes problematic.
Where possible (as is the case with IDisposable) I prefer to rely on the public contract. Working against the contract in this instance would mean I am safe from underlying implementation changes.

Although you rarely have to manually dispose in C# imo, you could try it like this:
public void Show()
{
using (Form1 f = new Form1())
{
f.ShowDialog();
}
}
Then at the last accolade of the using part it will get disposed of automatically.

ShowDialog has side effect of keeping the GDI objects alive. In order to avoid GDI leak we need to dispose the ShowDialog appropriately. Where as Show method does not have any implication and GDI will be released appropriately. It is recommended to dispose the showDialog and do not rely on Garbage collector.

You could simply do:
using (var f = new Form1())
f.ShowDialog();

If you want to explicitly dispose, use
using(Form1 f = new Form1()){
f.ShowDialog();
}
This ensures Dispose() is called, as well as it occurs immediately

In your specific example, no, it's unlikely that it would be particularly useful. Forms do not hold onto a significant amount of resources, so if it takes a little bit longer for some portion of it's code to get cleaned up it isn't going to cause a problem. If that form just happens to be holding onto a control that is used to, say, play a video, then maybe it's actually holding onto some significant number of resources, and if you actually do dispose of those resources in the dispose method then it's worth taking the time to call dispose. For 99% of your forms though, their Dispose method will be empty, and whether you call it or not is unlikely to have any (or any noticeable) effect on your program.
The reason that it's there is primarily to enable the ability to dispose of resources in those 1% of cases where it's important.
It's also worth noting that when a Form is closed its Dispose method is already being called. You would only ever need to add a using or explicit Dispose call if you want to dispose of a Forms resources before that form is closed. (That sounds like a generally bad idea to me). This is easy enough to test. Just create a project with two forms. Have the second form attach an event handler to the Disposing event and show a message box or something. Then when you create an instance of that form and show it (as a dialog or not) you'll see that when you close it the message box will pop up right away, even if you keep the 'Form' instance around and without you ever needing to add a using or Dispose call.

Yes, you need and MUST call Dispose or use using statement, otherwise it can be, that instance remains in memory.
You can check it, if you put a Timer to the form and set a break point in the Timer.Tick handler. Even after closing the form without Dispose the handler will be called.