CODEWITHSUNDEEP
.netgarbage-collection
Nitin Midha
Nitin Midha

Reputation: 2268

Under what circumstances, we need to call GC.Collect twice

We have a WPF application, based on Unity with MMVVVM pattern. In application life cycle there can be several project life cycles, after each project life cycle we do a manual Tear Down and try to free all the reference of ViewModels. For event subscriptions with Unity we are using Weak references. So we are assuming that after tear down, we may call GC Collect, so that all the garbage objects are garbage collected. We have another option of manually un-subscribing all the events, but we are preferring garbage collection because it will clear around 200MB for us, which will facilitate new project loading.

With one instance, we are observing that, If i call GC.Collect only one time, its reference still remains in memory for sometime.

GC.Collect();
GC.WaitForPendingFinalizers();

But if i try Calling GC twice in a row, its cleans up everything nicely.

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

Any thoughts or pointers will be highly appreciated.

Update:

There are no Finalizers defined in Class.

Now i am also considering a case, in which this object is referred in another object which might have a finalizer. In Our framework, we have finalizer only for DBProvider, so i don't think, even this is the case.

Upvotes: 12

Views: 6444

Answers (4)

Ian Ringrose
Ian Ringrose

Reputation: 51897

You have a weak reference that you expect to be set to null, as you call GC and you believe that nothing is keeping the object alive.

I don’t know how weak references are implemented in .net, but it is very possible they delay the collection of objects and makes use of a system like finalizerrs.

Or it could be you have a object that needs to be finalized, as you have not call dispose() on it. (Very common with WPF or WinForms)

To find out, you need to use a MemoryProfiler, expect to spend at least a day leaning how to use any memory profiler, as you will be presented with a lot of data about objects internal to WPF. Personally I would download a free trail of Redgate’s memory profiler and have a go at seeing what the problem is, there support is also helpful. (Other memory profilers also work well, to a large extend it just depends on what you are used to.)

Upvotes: 0

Karthik Mahalingam
Karthik Mahalingam

Reputation: 1071

@Nitin, I am not sure whether my suggestion would help you or not, but as a rule of thumb we should avoid explicitly calling GC.Collect(). because it will likely to cause performance problem. Instead try to follow the proper disposal pattern.

Upvotes: 0

Henk Holterman
Henk Holterman

Reputation: 273179

If i call GC.Collect only one time, its reference still remains in memory for sometime.

Not really strange. When an object has a Finalizer (and no GC.SuppressFinalize() has been called on it), it gets a stay of execution (it is not collected, so that the finalizer can run with valid objects). All instances referenced by this object also get a stay of execution. A second round through the GC is needed to clean it all up.

On the other hand, most programs, inlcuding big and complex ones, should be able to run without calling GC.Collect() even once. And you want to call it twice...

after each project life cycle we do a manual Tear Down

Sounds complicated and easy to avoid... How many refernces are there into your Domain/View models? Ideally you would just cut 1 or 2 references to a 'main' object and forget about it.

Upvotes: 7

Jon Skeet
Jon Skeet

Reputation: 1500055

Sounds like you have something with a finalizer, basically - if you only call GC.Collect() once, the finalizers are finishing but the finalized objects aren't being collected.

Whether or not that represents a bug is a different matter. Generally it's not a good idea for there to be finalizers which actually need to be executing, but maybe it's okay in your case.

Upvotes: 13

Related Questions