.NET Memory Leaks

Posted by Jonathan Allen on Apr 13, 2007

Sections

Development

Topics

.NET Framework ,

.NET ,

Dynamic Languages

Tags

Memory Leaks

A problem with .NET that isn't talked about is the problems caused by using dynamic code generation. In a nut shell, dynamic code generation, which is used in XML Serialization, Regular Expressions, and XSLT transformations, can lead to memory leaks.

While the Common Language Runtime (CLR) can unload whole App Domains, it cannot unload individual assemblies. Code generation relies on creating temporary assemblies. These assemblies are often loaded into the primary app domain, meaning that cannot be unloaded until the application exits.

For libraries like XML Serialization, this isn't much of a problem. Usually the serialization code for a given type is cached, which limits the application to one temporary assembly per type. But there are XMLSerializer overloads that don't use caching. If a developer uses one of these without providing some sort of application-level cache, memory can be slowly leaked as new instances of essentially the same code is loaded into memory. For more information specifically on XML, see .NET Memory Leak: XmlSerializing your way to a Memory Leak.

The potential problems are far worse for code that habitually rewrites itself at runtime such as those written in LISP. For that sort of language, either the code has to be run entirely interpreted, that is never being compiled to IL code, or placed in separate AppDomains that can be purged from time to time. Either way, it poses a challenge for language developers targeting the Common Language Runtime.

1. Back to top

   What about dynamic proxies ?

   by Sadek Drobi

   What about dynamic proxies generated by projects like Castle and Spring?

   Reply

2. Back to top

   Re: What about dynamic proxies ?

   by Jonathan Allen

   Any framework that emits IL at runtime has the potential for a memory leak, but without in-depth knowledge of the code or running a profiler I cannot say for certain. I would suggest contacting the respective teams or using reflection to see if the number of loaded assemblies is growing over time.

   Reply

3. Back to top

   Re: What about dynamic proxies ?

   by Stefan Wenig

   Castle caches everything by default, and I'd be very surprised if spring.net wouldn't. The fact that assemblies cannot be individually unloaded is well known after all. With DynamicProxy, you usually create a small number (often 1) of proxy classes for a number of classes in assemblies that are already referenced statically. Memory usage in these scenarios is usually quite flat. I've never seen a situation where the lack of unloading of dynamic proxies actually leads to problems.
   With regex and XSLT you have to be careful: if you compile input to your app, you'll eventually run out of memory. compilation should therefore only be enabled for app resources (i.e., regular expression or XSL-files that you created and delivered with your app).
   For dynamic proxies to leak in the same way, you'd have to dynamically load assemblies in your default app domain. Leaking-wise, you'd be doomed even without dynamic proxies.

   Reply

4. Back to top

   DynamicMethod

   by Stefan Wenig

   The article should mention that .net 2.0 includes a new mechanism called DynamicMethod. It's a way to generate IL code that is basically garbage collected like any other object. It can only generate methods though, not types.

   Reply

• Older >