[2.0] issue on memory management
Hi all,
We in the team have an issue|debit about the coding standard in terms in memory management.
We have 2 codes that we proposed and we need to choose the better one.
// code1
Code:
{
object o1 = null;
try
{
using (o1 = new object}
{
// code here
}
}
catch
{ // code here
}
finally
{
o1 = null;
}
}
vs
code2
Code:
{
try
{
using (object o1 = new object}
{
// code here
}
}
catch
{ // code here
}
}
Code2 dispose the object but not set to null. And if you what is your choice? code 1 or code 2. Any inputs, idea. Thanks!
Popskie
Re: [2.0] issue on memory management
Code 2 is actually better and the right way of doing this. When you use using statement, the compiler will take care of releasing the object.
Re: [2.0] issue on memory management
Quote:
Originally Posted by Shuja Ali
Code 2 is actually better and the right way of doing this. When you use using statement, the compiler will take care of releasing the object.
But if the object are not set to null after it was dispose and try to excute a method from that given object it's still execute even though that object is disposed already. What do you think?
Popskie
Re: [2.0] issue on memory management
As I said the object will be created and destroyed within the using block. This is why when you execute the code second time it doesn't give you any error.
Re: [2.0] issue on memory management
Basically, the object is created again when entering the "using" statement so you don't have to worry about it.
And since o1 is a method local member (as I can see) it'll automatically loose value when method execution ends
Re: [2.0] issue on memory management
Both those code snippets are inappropriate. The 'using' block should enclose the 'try' block. It should look like this:
C# Code:
using (o1 = new object()
{
try
{
// ...
}
catch
{
// ...
}
}
The point of a 'using' block is to dispose an object at the end of the block regardless of what happens inside. The 'using' statement is shorthand for a 'finally' block. The code above is equivalent to this:
C# Code:
object o1 = new object();
try
{
// ...
}
catch
{
// ...
}
finally
{
o1.Dispose();
}
Note also that this has nothing to do with memory management. Object disposal has nothing to do with memory and everything to do with unmanaged resources. If you dispose an object it releases its unmanaged resources, e.g. file handles, window handles, etc. If you maintain a reference to that disposed object then the memory it occupies can still not be reclaimed. If you remove all references to an undisposed object its memory can still be reclaimed, although it will take multiple passes by the GC instead of just one.
Re: [2.0] issue on memory management
Quote:
Originally Posted by Shuja Ali
As I said the object will be created and destroyed within the using block. This is why when you execute the code second time it doesn't give you any error.
No, thats not my point here. My question is what is the best approach. After disposing the object. It is best, to set the object to null or not?
Ok now I understand according to JM if the object will dispose. Only the handle will close. But I want to erase that object in the memory and its reference, not only the handle. How to that?
Thanks JM for your comment. I appreciated that much.
Thanks,
Popskie
Re: [2.0] issue on memory management
Why exactly do you want to do this? It is not something you would or should normally do in a .NET app.
Re: [2.0] issue on memory management
Quote:
Originally Posted by jmcilhinney
Why exactly do you want to do this? It is not something you would or should normally do in a .NET app.
Ok JM I try to explain just give a comment if Im wrong.
1. If I dispose an object, it is mean that this object is subject for garbage collection?
Code:
objectname.Dispose();
2. If I dispose and set to null does it mean that this object are already collected by the GC or what happen?
Code:
objectname.Dispose();
objectname=null
JM thanks again I hope you can enlighten me.
Popskei
Re: [2.0] issue on memory management
Disposing an object releases unmanaged resources. That's it, that's all.
Setting a variable to null writes all zeroes to the stack space allocated to that variable. That's it that's all.
As long as there are any references in existence for an object, i.e. any variables containing that object's memory address, then that object will be kept alive. When the last reference to an object is removed it becomes eligible for garbage collection, i.e. to have the memory it occupies reclaimed. Note that the fact that an object is eligibale for garbage collection says nothing about when it be cleaned up. That's up to the garbage collector.
Now, there are basically two ways to remove a reference to an object:
1. A variable that refers to the object can lose scope. Once a variable loses scope it ceases to exist. If the variable ceases to exist then so does the reference to the object.
2. A variable that refers to the object can have a different address assigned to it. This different address could be that of some other object or it could be zero, i.e. no object. The way to write a zero address to a variable is to set it to null.
Note that there is no point using method number 2 if method number 1 would happen anyway. Setting a local variable to null at the end of a method is completely pointless.
Now, an object can be marked as eligible for garbage collection whether it has been disposed or not. If the GC tries to cleanup an object and finds that it has not been disposed it will call its Finalize method to dispose it, which is exactly what the Finalize method is for. The GC will then have to perfrom more than one pass to cleanup the object. If you dispose your objects yourself then resources are released sooner and memory is reclaimed more efficiently.
If you fail to remove references to objects that are no longer used, THAT is a memory leak. If you fail to dispose an object but you do remove references then there will be no memory leak and no resource leak, although resource management will be suboptimal. If you fail to dispose and fail to remove references, you have a resource and memory leak.
Re: [2.0] issue on memory management
Thanks JM for the long explanation you put here. I learned a lot about this. I know the difference between setting to null and disposing.
I have one more question for you JM. what if my local variable is inside in the static method.It is still considired null if it is out of scope?