Google Website Translator Gadget

Thursday, 30 September 2010

Understanding MSIL Memory Leaks

We are using a custom RuntimeDataBuilder class that dynamically constructs a .NET type in-memory using Reflection.Emit to create simple property getters/setters for the information that we receive from a generic WCF Data Service. The service exposes a "DataSet like" structure consisting out of 1..m DataTableDefinition classes each containing 1..m DataTableColumnDefinition classes. When the information is received client side, we generate the dynamic type with its property setters/getters to improve the performance and facilitate binding on our Silverlight client. All of this works fine.

I’m currently trying to figure out how the memory management for these custom dynamic types work.  I’m thinking that we might be causing a possible memory leak if we regenerate the type. Reason why I am contemplating this is that the user can change the query parameters which may then result in more/less information coming across the wire. It therefore invalidates the previous type that I created and I want to make sure that I’m are able to free up the memory used by this previous type definition as this can happen quite frequently.  From this article on MSDN we gather that if you are using Light Weight Code Generation (LCG) the code is allocated on the managed heap which will be reclaimed by the GC when there is nothing holding a reference to it. But LCG only seems to apply to dynamic methods. My concern is for the Type with all its property getters/setters that is now not required anymore. If this is allocated on the unmanaged heap our only hope for reclaiming the memory seems to be to make sure that the type is loaded into a temporary AppDomain that we can unload when it is not required anymore.  This opens up a whole new can of worms for inter AppDomain communication which I would rather avoid.

So my question is any of my readers can shed some more light on this topic.  Is my assumption correct or is there another way of reclaiming the memory?  I also posted the question to StackOverflow if you are interested in checking out the responses over there.  Thx :-)

2 comments:

  1. Mmm, seems like my suspicion has been confirmed. We are indeed leaking memory when we regenerate the type. See the following links for other people raising the same issue and also a MS connect issue with a work around to minimize the impact. Not ideal, but at least something:

    http://stackoverflow.com/questions/2503645/reflect-emit-dynamic-type-memory-blowup

    https://connect.microsoft.com/VisualStudio/feedback/details/472622/severe-performance-decrease-when-generating-many-types-into-an-assemblybuilder

    ReplyDelete
  2. Also see http://www.infoq.com/news/2007/04/CLR-Memory-Leak as confirmation

    ReplyDelete