0

I have a confusion regarding these two seemingly contradictory statements on msdn..

1) When a class contains a destructor, an entry is created in the Finalize queue. When the destructor is called, the garbage collector is invoked to process the queue.

2) The programmer has no control over when the destructor is called because this is determined by the garbage collector. The garbage collector checks for objects that are no longer being used by the application. If it considers an object eligible for destruction, it calls the destructor (if any) and reclaims the memory used to store the object.

In the first statement i understand that Destructor calls ---> Garbage collector while as from the second statement i understand that Garbage collector calls ---> Destructor

??

Update: this link

tariq
  • 2,193
  • 15
  • 26

1 Answers1

4

First the garbage collector determines that an object is eligible for collection.

If the object requires finalization then it is placed on the finalization queue; it is now alive again because the queue is a root.

Then the finalizer thread runs, marks the object as no longer requiring finalization, and runs the finalizer.

If at the end of the finalizer the object is still dead then when the GC runs again later, it discovers that there is a dead object that does not require finalization, and cleans it up.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • You mean GC calls destructor which in turn leads to finalize being called.. finilize executes marks it as 'no finalization needed'.. during next run gc removes it. so its GC calls ---> Destructor ?? – tariq Jan 17 '14 at 06:48
  • You mean first GC calls finalizer and again when GC runs only it will reclaim the memory? Does that mean objects with destructors atleast take 2 GC cycles to be cleaned up? or this happens immediately one after another? – Sriram Sakthivel Jan 17 '14 at 07:01
  • @SriramSakthivel: Yes, finalizable objects are (1) promoted to the next generation, and (2) are not actually released until the *second* GC that finds them dead. If you don't like that then **don't make destructors**. – Eric Lippert Jan 17 '14 at 07:16
  • @EricLippert , consider this .. "The destructor implicitly calls Finalize on the base class of the object. Therefore, the destructor code is implicitly translated to the following code:" protected override void Finalize() { try { // Cleanup statements... } finally { base.Finalize(); } } so there is actually no destructor in the translated code ? and GC leads to finalization ? – tariq Jan 17 '14 at 07:27
  • @EricLippert Thank you so much, Opened my eyes, I learnt something new today. :) ; One more question, So is that possible for an object can be alive even after `Finalized`? PS: [I read your answer here already](http://stackoverflow.com/a/4899622/2530848) – Sriram Sakthivel Jan 17 '14 at 07:31
  • @tariq: A destructor is simply a syntactic sugar for a `Finalize` method that calls the base class `Finalize` method. **The GC puts dead objects that need finalization on the finalizer queue**, which makes them **not dead**. – Eric Lippert Jan 17 '14 at 14:51
  • @SriramSakthivel: Yes, but doing so is very confusing. Suppose the finalizer copies `this` to a static field. Every static field is a root, so the object is alive again. – Eric Lippert Jan 17 '14 at 14:51