11

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.

Nitin Midha
  • 2,258
  • 20
  • 22
  • 8
    What's MMVVVM? The Roman way of coding? – DanDan Sep 30 '10 at 11:31
  • MVVM is common in WPF, but in our case, we have several different application in different .NET Technologies and they all are based on common DomainObject framework, So we decided a new Layer MV over our DomainObjects to facilitate our WPF applications. – Nitin Midha Sep 30 '10 at 12:13

4 Answers4

12

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.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • I checked with that particular class, as far i can see there are no finalizers. – Nitin Midha Sep 30 '10 at 12:07
  • Now i am considering a case, in which this object is referred in another object which might have a finalizer. – Nitin Midha Sep 30 '10 at 12:49
  • If any object has a finalizer, any objects to which it holds direct or indirect references will at least partially survive the next GC (finalizers, if any, will run on such objects; WeakReferences may survive, but I wouldn't trust that they always will). – supercat Sep 30 '10 at 15:29
  • Now, at another place, even when i am calling GC.Collect twice, its still not cleaning up the reference. – Nitin Midha Oct 05 '10 at 17:25
  • @Nitin: That sounds like you've still got a reference to the object then. – Jon Skeet Oct 05 '10 at 17:48
  • When i try to reproduce the behavior with Memory Profiler(yourkit) running on the application, it works just fine as expected, the viewmodel is not in the memory any more. So if i have a reference somewhere, then it should have been in Memroy Profiler also. – Nitin Midha Oct 06 '10 at 09:16
  • @Nitin: Do you still have the calls to WaitForPendingFinalizers? To be honest, this sort of investigation isn't really easy to do via sites like Stack Overflow :( – Jon Skeet Oct 06 '10 at 09:26
6

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.

H H
  • 263,252
  • 30
  • 330
  • 514
  • Actually whole project objects resides in memory including, V VM MV and M for Project life cycle, so we decided to do a manual tear down. Also i consider the case mentioned by you, please see comments on Jon Skeet answer. – Nitin Midha Sep 30 '10 at 13:06
  • I still don't see the need for a manual tear down. But it will be complex and you only need to miss one little ref... – H H Sep 30 '10 at 13:10
0

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.)

Ian Ringrose
  • 51,220
  • 55
  • 213
  • 317
0

@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.

Karthik Mahalingam
  • 1,071
  • 8
  • 10