| Author |
Message |
bsiegel
Joined: 30 Jun 2009 Posts: 2
|
Posted: Tue Jun 30, 2009 11:25 pm Post subject: Garbage collection during snapshot |
|
|
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 |
|
| Back to top |
|
 |
AndrewH
Joined: 17 Aug 2006 Posts: 137
|
Posted: Wed Jul 01, 2009 11:28 am Post subject: |
|
|
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 |
|
 |
|
|
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