Red Gate forums :: View topic - Garbage collection during snapshot
Return to RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
ANTS Memory Profiler Previous Versions
ANTS Memory Profiler Previous Versions forum

Garbage collection during snapshot

Search in ANTS Memory Profiler Previous Versions forum
Post new topic   Reply to topic
Jump to:  
Author Message

Joined: 30 Jun 2009
Posts: 2

PostPosted: Tue Jun 30, 2009 11:25 pm    Post subject: Garbage collection during snapshot Reply with quote


I am eval'ing Memory Profiler 5, and I'm confused on how Profiler's full garbage collection works.

There is a point in the execution of my app where a lot of items are released at once, and I am doing a garbage collection with GC.Collect() and GC.WaitForPendingFinalizers() afterwards. However this collection does not release any additional memory (watching it in Profiler does not show any change when these methods are called).

What is interesting is that as soon as I take a snapshot (when Profiler performs a full garbage collection), I can see the memory usage take a huge dive as all of those objects are finally freed.

So my question is: how does the garbage collection initiated by the profiler when you take a snapshot differ from simply calling GC.Colllect()?

--Brandon Siegel
Back to top
View user's profile Send private message

Joined: 17 Aug 2006
Posts: 137

PostPosted: Wed Jul 01, 2009 11:28 am    Post subject: Reply with quote

The profiler performs a single full garbage collection while taking a snapshot. It's invoked via a different .NET API but shouldn't have an effect that's any different from GC.Collect().

There are a few things that can cause .NET memory usage to appear not to change after a garbage collection:

* The # bytes in all heaps counter is often not accurate as it's only updated after a garbage collection, and there are times when .NET allocates more memory without causing a GC (and rare times when it releases memory outside of a GC). The private bytes counter is updated in real time.

* Fragmentation of the large object heap can prevent .NET from releasing memory back to the system. You can see free space in .NET heaps in the memory profiler, as well as the largest free contiguous block: if there is a lot of free space but the largest contiguous block is small then fragmentation is occurring.

* Objects referenced by objects with finalizers require at least 2 garbage collection cycles to be removed from memory, and possibly more if these references themselves have finalizers.

* .NET can maintain a pool of free memory for future object allocations if it thinks that there will be a lot of them (this allows it to postpone future garbage collections). It might decide to release this back to the system if there is another GC and not much of the free memory is used. This is often beneficial for the performance of server style applications.
Andrew Hunter
Software Developer
Red Gate Software Ltd.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group