DataSet and GC.SuppressFinalize

  • Thread starter Thread starter Raghu
  • Start date Start date
R

Raghu

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.

Thanks.
Raghu/..
 
Raghu said:
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?)
Click to expand...
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.
Click to expand...


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
 
Yes, we are sure about finalize queue. We used the !FinalizeQueue command in
sos.

You could be right about other objects holding references to the data sets.
In fact, we found some of our objects that has finalizers on them
(unnecessariliy).

Thanks for the information.
 
Raghu said:
Yes, we are sure about finalize queue. We used the !FinalizeQueue command
in
sos.

You could be right about other objects holding references to the data
sets.
In fact, we found some of our objects that has finalizers on them
(unnecessariliy).
Click to expand...

Use !dumpheap and !gcroot to see what's on the managed heap and why it's
there.

David
 
Back
Top