Menu
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.
668
@Peri: The point of doing it after form close is that you've just made a bunch of objects (controls, the data you were displaying) eligible for garbage collection - so by calling GC. Collect you're basically telling the garbage collector that you know better than it for a change.
You can call the Collect(Int32, GCCollectionMode, Boolean, Boolean) method to reduce the managed heap to the smallest size possible, as the following code fragment illustrates.
Excessive garbage collection activity can occur due to a memory leak in the Java application. Insufficient memory allocation to the JVM can also result in increased garbage collection activity. And when excessive garbage collection activity happens, it often manifests as increased CPU usage of the JVM!
Rule #2 Consider calling GC.Collect() if some non-recurring event has just happened and this event is highly likely to have caused a lot of old objects to die. A classic example of this is if you're writing a client application and you display a very large and complicated form that has a lot of data associated with it.
One useful place to call GC.Collect() is in a unit test when you want to verify that you are not creating a memory leak (e. g. if you are doing something with WeakReferences or ConditionalWeakTable, dynamically generated code, etc).
The GC needs to be called twice in order to get the ' Finalizers called - the first time in, it simply makes a list of what is to be finalized, ' the second time in, it actually does the finalizing. Only then will the object do its ' automatic ReleaseComObject.
In fact the code we use is: Utils.ReleaseCOMObject(objExcel) ' Call the Garbage Collector twice. The GC needs to be called twice in order to get the ' Finalizers called - the first time in, it simply makes a list of what is to be finalized, ' the second time in, it actually does the finalizing.
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.
84
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.
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
