Re: DataSet and GC.SuppressFinalize

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: David Browne (meat_at_hotmail.com)
Date: 03/09/05 

Date: Tue, 8 Mar 2005 21:32:26 -0600

"Raghu" <Raghu@Nospam.com> wrote in message
news:eOITXHEJFHA.1528@TK2MSFTNGP09.phx.gbl...
> We are having issues with DataSet and related objects. They are staying in
> the memory for too long. When we started investigating the problem,
> windows
> debugger (windbg) showed that they are in the finalization queue. This
> surprised us as we were not aware that they have finalizers defined.
>
> The .net framework code (mentioned in this email) is reverse engineered by
> Anarkino tool.
>
> Even though DataSet does not define a finalizer, it derives from
> MarshalByValueComponent (MBVC) which does implement finalizer. In
> addition,
> the DataSet does not define a Finalize method but the base class does.
> However the base class has only proteted Finalize method. This means only
> derived classes can call this method.
>
> The constructor of DataSet makes GC.SuppressFinalize(this) call. Thinking
> that we have to call Dispose method, we checked for Dispose method
> implementation on DataSet. Well, it is not there. But MBVC has it. To my
> surprise, it is making GC.SuppressFinalize(this) again in the MBVC's
> Dispose
> method. This means these objects will never be finalized (is this right?)
>

> That is 2 times we saw the GC.SuppressFinalize between DataSet and MBVC
> implementations. Can any one explain why the supress call is required when
> we are not using any typed datasets? Is there an elegant way to make them
> disappear faster (other than using ReRegisterForFinalize method)? This
> problem applies all classes the derive from MBVC.
>

GC.SupressFinalize(this) will remove the object from the finalization queue.
After this call it is as if the object was not finalizable. When found to
be unreachable it will not be moved to the FReachable queue. Instead it
will simply be collected.

Are you absolutely sure that you see DataSets in the finalization queue?
They should never be there since GC.SupressFinalize should have removed
them.

If WinDbg/SOS show them as being reachable from the FReachable queue it may
be because some other finalizable object holds a reference to them.

David

Relevant Pages

  • Re: DataSet and GC.SuppressFinalize
    ... > that we have to call Dispose method, ... But MBVC has it. ... GC.SupressFinalizewill remove the object from the finalization queue. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Finalize Queue (WinDBG / SOS)
    ... If an object is in the finalization queue and its finalize bit is ON, ... > public BadClass() ... > class GoodClass: IDisposable ...
    (microsoft.public.dotnet.framework)
  • Re: Class Instantiation Question
    ... But there is more to finalization than this. ... then a pointer to the object is placed on the finalization queue. ... The garbage collector scans the finalization queue looking for pointers to these objects. ... is removed from the finalization queue and appended to the freachable queue. ...
    (microsoft.public.vb.general.discussion)
  • Re: Question on Disposing of Resources
    ... Also keep in mind that .NET doesn't support deterministic finalization, ... > the public Dispose method - giving the "client" code the opportunity to ... > code was in the destructor, and you wanted the "client" code to have ... > over releasing the unmanaged resources, ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: GC.SuppressFinalize
    ... If IDisposable.Dispose is being invoked there is at least one reference to ... You can suppress finalization at any point in the method with ... finalization in the interim. ... > GC.SuppressFinalize method at the end of the Dispose method. ...
    (microsoft.public.dotnet.framework)