none
GC.SuppressFinalize - question RRS feed

  • Question

  • If an object calls suppress finalize on itself, does this ONLY prevent calls to its destructor (finalizer) or is the system clever enough to ALSO not bother putting the object on the finalization queue?

    We are all reminded how costly finalziers are, but I can find no answer to this question.

    If the system is clever, then the extra non-trivial cost will ONLY arise if a) we have declared a finalizer and b) have not yet called SuppressFinalize.

    The docs all seem to imply that the cost is high just by declaring a finalizer, even if we tell the system we don't want it to be called.

    An object cannot be on the finbalization queue if it is able to call suppress, because by defintion the object is still in use.

    So it would make a great deal of sense to not only suppress calls to the finalizer but also to say "Hey, this guy doesn't want his finalizer to be called, so we need not even bother putting this guy on the finalizer queue at all".

    It either does this OR it puts the object onto the finalizer queue KNOWING there is no need to do so, and then when taking it off, saying "Oh look, we don't need to call the finalizer for this guy" which would be silly.

    Does anyone know? is it documented?

    Cap'n

     

     

    Friday, July 2, 2010 2:12 PM

Answers

  • It's not imperative that the finalizer appear with the Dispose method.  That's only a pattern that's recommended, mostly for dealing with unmanaged data.  It's much more efficient to simply call the Dispose method and to NOT implement the finalizer than to supplement the Dispose method with a finalizer.

     

    The finalizer not only takes longer to allocate and deallocate for bookkeeping purposes but it also perpetuates generation promotion in the GC for any associated objects, causing more memory pressure and preventing early collection.

    Even if you suppress the finalization, you're doing so programmatically.  The type itself includes the finalization definition and so any instantiation will automatically perform the resources for finalization. 

    • Marked as answer by SamAgain Friday, July 9, 2010 8:51 AM
    Wednesday, July 7, 2010 6:56 PM

All replies

  • It will not be put on the finalization queue.

    Friday, July 2, 2010 11:19 PM
  • It will not be put on the finalization queue.


    Thanks for a straight answer, this helps a great deal.

    This means then, that the oft seen blanket statement

    "Having a finalizer in your class is very expensive"

    is false. What we should be told is

    "A finalizer in your class is very expensive thing, unless the Dispose method is called on such objects and the Dispose method supresses finalization".

    Do you agree?

    Cap'n

     

    Saturday, July 3, 2010 1:40 AM
  • It's still more expensive than if you don't have a finalizer at all - GC will still need to do some book keeping to remember the fact it's a finalizable object. And we need to scan this list when we do a GC to know whether we need to put stuff on the finalization queue or not. 

    So, don't have finalizable objects unless you have a good reason to; and call Suppress if you don't need GC to schedule your finalizers to run. 

    Saturday, July 3, 2010 5:52 PM
  • It's not imperative that the finalizer appear with the Dispose method.  That's only a pattern that's recommended, mostly for dealing with unmanaged data.  It's much more efficient to simply call the Dispose method and to NOT implement the finalizer than to supplement the Dispose method with a finalizer.

     

    The finalizer not only takes longer to allocate and deallocate for bookkeeping purposes but it also perpetuates generation promotion in the GC for any associated objects, causing more memory pressure and preventing early collection.

    Even if you suppress the finalization, you're doing so programmatically.  The type itself includes the finalization definition and so any instantiation will automatically perform the resources for finalization. 

    • Marked as answer by SamAgain Friday, July 9, 2010 8:51 AM
    Wednesday, July 7, 2010 6:56 PM