Garbage collection during snapshot
bsiegel
Posts: 3
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
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
Comments
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.
Software Developer
Red Gate Software Ltd.