CompositionContainer hierarchies & Memory leaking like mad

Oct 25, 2011 at 10:20 AM

Hello,

this is for MEF .NET 4.0 (i.e. .net framework 4.0 current patch level)

I am hunting down a memory leak regarding composition containers. I ahve quite a lot of thm forming ahierachy. They have partially scoped content.

The memory leak I am trying to find resolves around them listening to changees of the parent which I seemingly am unable to get rid of.

My profiler shows me my biggest adding is in a half an hour test 22.17 million (!) new nistances of System:Threading.ReaderSWriterCount[]. I start thinking that with all the hierarchical CompositonContainers being created I am slowly leaking instances of dynamically created types that never get released.

Questions:

* When I get a non-shared export from a composition container, is the composition container maintaining a link? Usnig GetExportedValue, do I HAVE to ReleaseExport later?

`* Is there any way to centrally disable the whole recomposition mechanism? We do not use it (modules are identified static when loading), and all the event hookups are overhead, obviously.

Oct 25, 2011 at 4:49 PM

Hi,

To answer your questions:

· Yes – you must always release all exports that you retrieve from the container. The easier way to do this is to use GetExport<T> rather than GetExportedValue<T> - the returned Export<T> object is disposable.

· When you create containers, you can specify the CompositionOptions.DisableRecomposition flag to completely disable recomposition. I’m not certain that this will solve your issue though.

Another thing that might be useful tracking this down – whenever you create a child CompositionContainer, make sure you also Dispose() it once you’re done.

Nick

From: NetTecture [email removed]
Sent: Tuesday, October 25, 2011 2:21 AM
To: Nicholas Blumhardt
Subject: CompositionContainer hierarchies & Memory leaking like mad [MEF:277095]

From: NetTecture

Hello,

this is for MEF .NET 4.0 (i.e. .net framework 4.0 current patch level)

I am hunting down a memory leak regarding composition containers. I ahve quite a lot of thm forming ahierachy. They have partially scoped content.

The memory leak I am trying to find resolves around them listening to changees of the parent which I seemingly am unable to get rid of.

My profiler shows me my biggest adding is in a half an hour test 22.17 million (!) new nistances of System:Threading.ReaderSWriterCount[]. I start thinking that with all the hierarchical CompositonContainers being created I am slowly leaking instances of dynamically created types that never get released.

Questions:

* When I get a non-shared export from a composition container, is the composition container maintaining a link? Usnig GetExportedValue, do I HAVE to ReleaseExport later?

`* Is there any way to centrally disable the whole recomposition mechanism? We do not use it (modules are identified static when loading), and all the event hookups are overhead, obviously.

Oct 27, 2011 at 2:47 PM

Sorry, you lost me.

* CompositionContainer has no override that has CompositionOptions in 4.0 ;) Not using the codeplex drop yet - i likely start changing on next release.

* GetExport<T> does return a Lazy<T> which incidentally is... not disposable. http://msdn.microsoft.com/en-us/library/dd833492.aspx has the valid signature that I also see... How would you do it under this condition?

So, sadly both tips not applicable at the moment ;)

Any ideas? I am also happy with a newer more documented drop, then I likely move this project over...

Oct 27, 2011 at 4:50 PM
Edited Oct 27, 2011 at 4:50 PM
The memory leak I am trying to find resolves around them listening to changees of the parent which I seemingly am unable to get rid of.

You must dispose each CompositionContainer when you are done with it. That will unhook those ExportsChanged and ExportsChanging event handlers.

Oct 27, 2011 at 5:33 PM

Ah – thanks J .. I think the third point, also made by @wcoenen, probably the important one anyway, namely, you need to dispose all containers once you’re done with them.

GetExport<T>() returned an Export<T> somewhere off in the deep distant past I think. The correct way to release a Lazy<T> export is using ReleaseExport() - http://msdn.microsoft.com/en-us/library/dd986511.aspx

Cheers,
Nick

From: NetTecture [email removed]
Sent: Thursday, October 27, 2011 6:48 AM
To: Nicholas Blumhardt
Subject: Re: CompositionContainer hierarchies & Memory leaking like mad [MEF:277095]

From: NetTecture

Sorry, you lost me.

* CompositionContainer has no override that has CompositionOptions in 4.0 ;) Not using the codeplex drop yet - i likely start changing on next release.

* GetExport<T> does return a Lazy<T> which incidentally is... not disposable. http://msdn.microsoft.com/en-us/library/dd833492.aspx has the valid signature that I also see... How would you do it under this condition?

So, sadly both tips not applicable at the moment ;)

Any ideas? I am also happy with a newer more documented drop, then I likely move this project over...