Dynamically created proxies and virtual memory

[jono.pare]

Hi,
I have a question about the dynamically compiled proxies that we get when using all the cool AOP functionality in spring.net: if I create enough of them, will I eventually run out of virtual memory in my process? I ask because I'm not sure if .NET provides a way to "unload" types (or allow them to be garbage collected), and if we're continuously adding new types (created on demand) then surely this will over time add pressure on our addressable memory space? I'm not asking for any solutions (I'm sure that using separate app domains or recycling processes would both suffice in most cases) I'm just curious about the behaviour and I felt sure somebody in this group would be able to point me to the answer.
Many thanks,
Jono

[Stingray]

Hi,

We've had no problems regarding virtual memory with spring.
.Net does do garbage collection.
Why don't you run a profiler like redgate with one the sample spring apps, you'll see it adds very little overhead.

Cheers,

[Erich Eichinger]

Hi,

Spring AOP Proxies are generated using Reflection.Emit. Indeed this causes the memory to fill up, since the CLR unfortunately does not garbage collect dynamically generated types (except when unloading the AppDomain) - more specifically it is not possible to unload assemblies once the are loaded. This also applies to dynamic assemblies.

The memory leakage should be only a few bytes per generated type though, so you'd need to generate really lots of them.

It is also worth mentioning that Spring.NET caches proxy types once they are generated based on their proxy configuration to keep the footprint low.

hth,
Erich

[jono.pare]

Hi Erich,
Many thanks for your reply. I was unaware that a cache existed and I'm glad that it does: I frequently come across long-lived processes that are forever creating new proxies (most just proxy the same set of underlying types); without this kind of cache I suppose I'd already have seen my hypothetical problem in the wild.
Regards,
Jono