Memory management in the .NET Framework

Garbage Collection in the .NET Framework « Tim.GetInstance( )

Garbage Collection in the .NET Framework « Tim.GetInstance( ) — Fri, 20 Apr 2007 18:22:02 GMT

PingBack from http://bigtunatim.wordpress.com/2007/04/20/garbage-collection-in-the-net-framework/

re: Memory management in the .NET Framework

JohanS — Mon, 23 Apr 2007 10:30:35 GMT

I updated the post. I re-read it and thought that the "What happens during GC?" section could be a bit more elaborate.

Mea culpa / Johan

re: Memory management in the .NET Framework

Pini Usha — Sat, 28 Apr 2007 21:32:57 GMT

Hi,

You state to avoid 85k or bigger objects, but

how can I measure the size of my object?

re: Memory management in the .NET Framework

JohanS — Wed, 02 May 2007 16:21:51 GMT

The immediate answer to this question is to do what I describe in http://blogs.msdn.com/johan/archive/2007/01/11/i-am-getting-outofmemoryexceptions-how-can-i-troubleshoot-this.aspx

This might be a bit more low-level approach than you expected, but it really is a good way to look at what you're populating the stack with.

However; as I tried to describe in my post you only need to pay attention to the individual elements. If your object conatins nine 10 KB strings, then the strings are stored as individual elements and the object itself only contains references to the strings. So nothing would end up on the large object heap.

If you had an object with one 90 KB string, though, the string would be on the large object heap, but the object itself would not.

/ Johan

re: Memory management in the .NET Framework

Jeremy Wiebe — Sun, 03 Jun 2007 18:04:34 GMT

In your last point you say "Don't use finalizers"... Am I correct in assuming that doesn't include classes that are written using the IDisposable pattern where the code uses deterministic finalization?

re: Memory management in the .NET Framework

JohanS — Mon, 04 Jun 2007 08:22:50 GMT

Hi Jeremy,

You're absolutely correct in your assumption.

Deterministic finalization is a whole other ballgame. The reason why you wouldn't use (and more importantly; rely 100% on) finalizers is because they will get invoked by the GC, and thereby be promoted to the next generation. That doesn't apply if you use the IDisposeable pattern correctly.

There is a potential risk in the fact that people tend to ignore calling .Dispose, but if implemented and executed correctly it is great.

.NET Tips & Tricks

Michael's Coding Den — Wed, 13 Jun 2007 22:17:57 GMT

Last update: June 13 , 2007 Document version 0.6 Preface If you have something to add, or want to take

Top 20 .NET Garbage Collection (GC) Articles

roy ashbrook — Sun, 24 Jun 2007 20:29:53 GMT

Ah. Garbage Collection... how I love and hate thee. =P I think one sad thing about programming in .net

Lot's of objects on the Large Object Heap on a 64-bit server

Speaking of which... — Thu, 27 Mar 2008 11:17:16 GMT

My colleague Tess showed me a dump today which I thought was really interesting. The scenario was as

The KB article every one should know about

Speaking of which... — Thu, 27 Mar 2008 11:18:32 GMT

Have you read http://support.microsoft.com/?kbid=307340 ? If not, I suggest you do so. If you need convincing

Finalizers and weak references

Speaking of which... — Thu, 27 Mar 2008 11:18:55 GMT

What do finalizers and weak references have in common? Well more than you might think actually. Finalizers

.NET Memory Management – Resources

Scott Dorman's Blog — Sun, 11 Jan 2009 02:41:17 GMT

Note : This entry was originally posted on 9/14/2008 5:16:11 PM. I present at a lot of the local Florida