.NET Memory Leaks

by Jonathan Allen on Apr 13, 2007 |

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.

Related Editorial

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

eBook: The New Kingmakers - How Developers Conquered the World

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Betfair Chooses not to Gamble with Database Performance: An AppDyanmics Case Study

10 Key Guide Points for Continuous Delivery

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

What about dynamic proxies ? by Sadek Drobi Posted

Re: What about dynamic proxies ? by Jonathan Allen Posted

Re: What about dynamic proxies ? by Stefan Wenig Posted

DynamicMethod by Stefan Wenig Posted

What about dynamic proxies ? by Sadek Drobi

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

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.

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.

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.