Garbage collection during snapshot

Memory profiling for .NET developers

Moderators: StephenC, Alex.Davies, AndrewH, melvyn.harbour

Garbage collection during snapshot

Postby bsiegel » Tue Jun 30, 2009 11:25 pm

Hi,

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
bsiegel
 
Posts: 2
Joined: Tue Jun 30, 2009 11:19 pm

Postby AndrewH » Wed Jul 01, 2009 11:28 am

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.
AndrewH
 
Posts: 134
Joined: Thu Aug 17, 2006 3:44 pm


Return to ANTS Memory Profiler Previous Versions

Who is online

Users browsing this forum: No registered users and 0 guests