Finalize method
-
Hi, I would like to know what does a finalize method does. I have got to know that when a finalizable object is unreachable then garbage collector removes its reference from finalizablr block and puts in freachable block and calls the finalize method and then frees the memory. So what is the essense of having the finalize method and not having it. Thanks in Advance: Rakesh
Rakesh
-
Hi, I would like to know what does a finalize method does. I have got to know that when a finalizable object is unreachable then garbage collector removes its reference from finalizablr block and puts in freachable block and calls the finalize method and then frees the memory. So what is the essense of having the finalize method and not having it. Thanks in Advance: Rakesh
Rakesh
The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
-
The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
-
Cool answer graham.I am greatful to you. It would be great if you clear me one more thing. What do you mean by unmanaged resource(memory,...)here? Thanks:
Rakesh
any resource not allocated by the CLR, and hence not garbage collectible. Some .Net framework classes interface to code written in c or c++ that allocates memory (or file handles, or network connection handles, etc.) outside of that managed by the CLR. All of these implement IDisposable and have finalize methods that insure that memory is released. User written classes that interact with COM objects or system dlls can also have unmanaged memory (received from the non-.Net objects used), and therefore need finalizers and should implement IDisposable to allow early (deterministic) release of those resources. This article[^] has a more detailed explanation of CLR meory management
-
The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
Rob Graham wrote:
The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
I'm a bit confused by this stuff at the moment. I read this article[^] and it seemed to suggest that a finaliser is required as a back up in case the person using your class does not call Dispose() when they are finished with the object. For example, if I have a class A that has a reference to another dot net class B and attaches to events on B in the constructor where do I unattach from the event? If I put it in a Dispose() method and the user of the class does not call Dispose() on it what happens? The article above seemed to suggest that I should implement a Finalizer to handle this case
System.IO.Path.IsPathRooted() does not behave as I would expect
-
any resource not allocated by the CLR, and hence not garbage collectible. Some .Net framework classes interface to code written in c or c++ that allocates memory (or file handles, or network connection handles, etc.) outside of that managed by the CLR. All of these implement IDisposable and have finalize methods that insure that memory is released. User written classes that interact with COM objects or system dlls can also have unmanaged memory (received from the non-.Net objects used), and therefore need finalizers and should implement IDisposable to allow early (deterministic) release of those resources. This article[^] has a more detailed explanation of CLR meory management
Thanks a lot Graham. Please clear me one more general question: Lets say that I have created an object and did some thing and then the application got crashed. Now will the garbage collector will reclaim the memory of this object and the resources it is pointing to?
Rakesh
-
Rob Graham wrote:
The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
I'm a bit confused by this stuff at the moment. I read this article[^] and it seemed to suggest that a finaliser is required as a back up in case the person using your class does not call Dispose() when they are finished with the object. For example, if I have a class A that has a reference to another dot net class B and attaches to events on B in the constructor where do I unattach from the event? If I put it in a Dispose() method and the user of the class does not call Dispose() on it what happens? The article above seemed to suggest that I should implement a Finalizer to handle this case
System.IO.Path.IsPathRooted() does not behave as I would expect
Josh Gray wrote:
I read this article[^] and it seemed to suggest that a finaliser is required as a back up in case the person using your class does not call Dispose() when they are finished with the object.
That is correct. The preferred method of handling objects that uses unmanaged resources is to call the Dispose method. That way the programmer can control when the resources are being freed. The finalizer is called by the garbage collector when the object is collected, if the Dispose method has not been called. The problem with this is that you can not predict when this will happen, and there isn't even any guarantee that the finalizer will ever be called. If there are a lot of objects in the finalizer queue when the program ends, it's not certain that all of them will be handled before the system decides that it takes too long to finalize all the objects, and just kills off the rest.
Josh Gray wrote:
For example, if I have a class A that has a reference to another dot net class B and attaches to events on B in the constructor where do I unattach from the event? If I put it in a Dispose() method and the user of the class does not call Dispose() on it what happens? The article above seemed to suggest that I should implement a Finalizer to handle this case
It's good to have a finalizer as a fallback. That way the object will be disposed eventually (at least in most cases) if the programmer fails to call Dispose properly.
--- It's amazing to see how much work some people will go through just to avoid a little bit of work.
-
Hi, I would like to know what does a finalize method does. I have got to know that when a finalizable object is unreachable then garbage collector removes its reference from finalizablr block and puts in freachable block and calls the finalize method and then frees the memory. So what is the essense of having the finalize method and not having it. Thanks in Advance: Rakesh
Rakesh
rockyl wrote:
I have got to know that when a finalizable object is unreachable then garbage collector removes its reference from finalizablr block and puts in freachable block and calls the finalize method and then frees the memory.
That will not happen. An object is not finalized when it's unreachable, it's just left untouched in memory until the next garbage collection. If you want to free any resources, the class should implement IDisposable, so that you can call Dispose to tell the object that it won't be used any more. At the garbage collection, if there is a finalizer in the class and GC.SuppressFinalize has not been called for the object, the object will be placed in the finalizing queue instead of being collected. A background thread is calling the finalizer for the objects in the queue, and after that the objects are up for collection.
--- It's amazing to see how much work some people will go through just to avoid a little bit of work.
-
Rob Graham wrote:
The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
I'm a bit confused by this stuff at the moment. I read this article[^] and it seemed to suggest that a finaliser is required as a back up in case the person using your class does not call Dispose() when they are finished with the object. For example, if I have a class A that has a reference to another dot net class B and attaches to events on B in the constructor where do I unattach from the event? If I put it in a Dispose() method and the user of the class does not call Dispose() on it what happens? The article above seemed to suggest that I should implement a Finalizer to handle this case
System.IO.Path.IsPathRooted() does not behave as I would expect
You can also take a look at this article: http://www.codeproject.com/useritems/idisposable.asp[^] The scenario you are describing is generally called "weak references" and isn't really supported in .NET. There are some blog posts about it, you can search on Google for them if you are interested. Keep in mind that when you implement a finalizer, you are incurring extra costs to using your object so you should only implement a finalizer if you have a very good reason. Every object that has a finalizer is put on a finalization queue when it is allocated, even if the finalizer is not run. The finalizer will only be run when your object is garbage collected AND it has not already been disposed.
----------------------------- In just two days, tomorrow will be yesterday.
-
rockyl wrote:
I have got to know that when a finalizable object is unreachable then garbage collector removes its reference from finalizablr block and puts in freachable block and calls the finalize method and then frees the memory.
That will not happen. An object is not finalized when it's unreachable, it's just left untouched in memory until the next garbage collection. If you want to free any resources, the class should implement IDisposable, so that you can call Dispose to tell the object that it won't be used any more. At the garbage collection, if there is a finalizer in the class and GC.SuppressFinalize has not been called for the object, the object will be placed in the finalizing queue instead of being collected. A background thread is calling the finalizer for the objects in the queue, and after that the objects are up for collection.
--- It's amazing to see how much work some people will go through just to avoid a little bit of work.
Guffa wrote:
At the garbage collection, if there is a finalizer in the class and GC.SuppressFinalize has not been called for the object, the object will be placed in the finalizing queue instead of being collected. A background thread is calling the finalizer for the objects in the queue, and after that the objects are up for collection.
The object is actually placed on the finalization queue when it is allocated. The
GC.SupresFinalizecall is important to tell the garbage collector that this object has been properly disposed and that it doesn't need to run the finalizer.----------------------------- In just two days, tomorrow will be yesterday.
-
Guffa wrote:
At the garbage collection, if there is a finalizer in the class and GC.SuppressFinalize has not been called for the object, the object will be placed in the finalizing queue instead of being collected. A background thread is calling the finalizer for the objects in the queue, and after that the objects are up for collection.
The object is actually placed on the finalization queue when it is allocated. The
GC.SupresFinalizecall is important to tell the garbage collector that this object has been properly disposed and that it doesn't need to run the finalizer.----------------------------- In just two days, tomorrow will be yesterday.
Scott Dorman wrote:
The object is actually placed on the finalization queue when it is allocated.
I checked up on this, and you are correct. I find it a bit misleading to call the entire list of finalizable objects a queue, though, as it's not really a queue. What do we call the queue in the queue, that contains the objects that actually are going to be finalized?
--- It's amazing to see how much work some people will go through just to avoid a little bit of work.
-
Scott Dorman wrote:
The object is actually placed on the finalization queue when it is allocated.
I checked up on this, and you are correct. I find it a bit misleading to call the entire list of finalizable objects a queue, though, as it's not really a queue. What do we call the queue in the queue, that contains the objects that actually are going to be finalized?
--- It's amazing to see how much work some people will go through just to avoid a little bit of work.
Guffa wrote:
I find it a bit misleading to call the entire list of finalizable objects a queue, though, as it's not really a queue.
You are correct, it isn't really a queue in the traditional understanding...it's really more of a list.
Guffa wrote:
What do we call the queue in the queue, that contains the objects that actually are going to be finalized?
Very good question. I think what you are referring to is the "freachable" queue. Check out these articles from Jeffery Richter: Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework[^] Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework[^]
----------------------------- In just two days, tomorrow will be yesterday.
-
Guffa wrote:
I find it a bit misleading to call the entire list of finalizable objects a queue, though, as it's not really a queue.
You are correct, it isn't really a queue in the traditional understanding...it's really more of a list.
Guffa wrote:
What do we call the queue in the queue, that contains the objects that actually are going to be finalized?
Very good question. I think what you are referring to is the "freachable" queue. Check out these articles from Jeffery Richter: Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework[^] Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework[^]
----------------------------- In just two days, tomorrow will be yesterday.
Scott Dorman wrote:
Guffa wrote: What do we call the queue in the queue, that contains the objects that actually are going to be finalized? Very good question. I think what you are referring to is the "freachable" queue.
That is right. That is the real finalization queue.
--- It's amazing to see how much work some people will go through just to avoid a little bit of work.
-
Scott Dorman wrote:
Guffa wrote: What do we call the queue in the queue, that contains the objects that actually are going to be finalized? Very good question. I think what you are referring to is the "freachable" queue.
That is right. That is the real finalization queue.
--- It's amazing to see how much work some people will go through just to avoid a little bit of work.
guys , if my understanding is right , is the following implementation correct for dispose finalise impementation? public class MyComponent : IDisposable { ..... public void dispose() { CleanUp(); GC.SupressFinalize(this); } public void CleanUp { //clean up code here } ~MyComponent { CleanUp(); } } Karam C Bose
-
guys , if my understanding is right , is the following implementation correct for dispose finalise impementation? public class MyComponent : IDisposable { ..... public void dispose() { CleanUp(); GC.SupressFinalize(this); } public void CleanUp { //clean up code here } ~MyComponent { CleanUp(); } } Karam C Bose