2

I create games manager which could select different games in region using PRISM MEF. There is a static shell and dynamic content in "MainRegion". Each game is separated module(assembly) and it's allocated about 20-30 MB for each game, when i getting instance.

I have such components for each game:

  • MainView [CreationPolicy.Shared]
    • View1 [CreationPolicy.Shared]
    • ViewN [CreationPolicy.Shared]
  • MainViewModel [CreationPolicy.Shared]
    • ViewModel1 [CreationPolicy.Shared]
    • ViewModelN [CreationPolicy.Shared]

Each "View"(main, 1st, 2nd...) created by calling

_serviceLocator.GetInstance<MainView>();

Each "View" has the following property

[Import(AllowRecomposition = false)]
public MainViewModel ViewModel //example for MainView
{
    get { return this.DataContext as MainViewModel; }
    set { this.DataContext = value; }
}

When I want to change game I remove MainView from MainRegion, but it doesn't create a new instance because PartCreationPolicy is set to Shared, but if I use NonShared it has a memory leak after the instance is removed.

How can I fix this memory leak in my application?

Adi Lester
  • 24,731
  • 12
  • 95
  • 110
Andrey Ashurko
  • 109
  • 1
  • 8
  • what do you mean by it has memory leak? Is it that you removed it and the the instance doesn't get destroyed or ? – TYY Apr 19 '13 at 17:53
  • instance destoryed, but TaskManager shows me that used memory didn't decrease, so if i choose the game once application uses 50 MB of memory, but if i'll choose the game much more times(go to menu-choose game-go to menu-choose game-...-...-etc.) it will "eat" more and more memory – Andrey Ashurko Apr 19 '13 at 18:05

1 Answers1

0

The key to solving the leak is to understand it first by using a memory profiler and determining the reason why the objects are being kept in memory and which object holds a reference to them.

As you don't provide such information in your question, I'll point that one very possible reason for this leak is that your objects implement IDisposable. There's a known issue with MEF keeping reference to disposable objects and not releasing them. If that's indeed the case, you can have a look at this question for more details and possible solutions: MEF keeps reference of NonShared IDisposable parts, not allowing them to be collected by GC. Another possibility is that one of your imports is configured to allow recomposition - in which case MEF will also keep a reference to your object.

You should also keep in mind that the GC performs garbage collection only when it needs to, and not necessarily right after you remove the instance. You can call the garbage collector yourself to make sure that the objects really are being kept in memory:

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

If your objects aren't disposable and don't have imports that allow recomposition then a reference to them is most likely kept by your own code, and you will have to profile your application to find out by whom. For that I would recommend using ANTS Memory Profiler.

Community
  • 1
  • 1
Adi Lester
  • 24,731
  • 12
  • 95
  • 110