Resources for geekSpeak - Garbage Collection with Jeffrey Richter
Thanks again to Jeffrey Richter who gave us great insight into the garbage collector.
Here are some useful links, followed by some questions that we didn't get to answer on the webcast.
MSDN Magazine article on the CLR Profiler - http://msdn.microsoft.com/msdnmag/issues/05/01/CLRProfiler/default.aspx
Download the CLR Profiler for the .NET Framework 2.0 http://www.microsoft.com/downloads/details.aspx?FamilyId=A362781C-3870-43BE-8926-862B40AA0CD0&displaylang=en
All about the .NET Micro Framework http://www.aboutnetmf.com/
BCL blog entry on SafeHandle http://blogs.msdn.com/bclteam/archive/2005/03/16/396900.aspx
Garbage Collection in the .NET Compact Framework (look towards the bottom of the page) http://msdn2.microsoft.com/en-us/library/aa446574.aspx
Is there good visual resource for understanding common garbage collection techniques that you would recommend?
I’m not sure what you mean. There are tools (like CLR Porfiler) that give you a visual representation of what’s in the heap. I don’t really know what you mean by “techniques”.
is gc.collect deterministic ? can gargabe collector ignore it and use it own heuristics on running it
Calling GC.Collect request that the GC run but it is just a request. You can’t command it to do anything. So, it is not deterministic and it can decide to use its own heuristics.
Any good references that explains and how to use Perfmon?
PerfMon has been around for many years and there has been much written about it. Also, you should read this: http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx
Could you please provide some advice on programming style/discipline to avoid managed heap fragmentation?
The garbage collector compacts memory and so fragmentation is not possible.
What CAN we do in recursion now that we couldn't do before?
You can write recursive algorithms just like you always wood. However, the deeper a threads stack, the harder the GC has to work to find out what’s garbage and what’s not garbage. So, for performance reason, you should try to avoid recursion.
You don't have to unregister the delegate in VB, only in C#
If you don’t want a delegate to forcibly keep an object alive, then you MUST unregister the delegate. This is true for all .NET languages including C# and VB.
What does garbage colletcion open up to us that we could not do before?
The main features are no memory leaks and no memory corruption. Another benefit is that there is easier coding since you never have to delete/free any memory. Also, there is just one heap and you allocate in it by calling new unlike the native world where there is VirualAlloc/HeapAlloc/malloc/Memory-mapped files/etc. There is no memory fragmentation issues. Also, a GC’d heap improves locality of reference reducing your working set which improves performance.
More on the heap fragmentation - how GC will defragment memory when I have a lot of memory pinned objects?
The GC can’t move pinned objects and so these can fragment memory. But, it is uncommon to have lots of pinned objects. Usually, when you make a P/Invoke call, the CLR pins some objects and then unpins the as soon as the call returns. For most applications, pinning has no noticeable impact.
Ancient history kind of question: Back in the days when Novell was a big competitor, the term "Ring Zero" was used to describe Microsoft's then dangerous way of providing access to key memory. Does the OS do garbage collection on Ring Zero memory the same way it does on our apps?
Kernel memory (ring zero) is not garbage collected today; maybe this will change in the future.
When calling a long running method asynchronously, I know that in the 1.1 framework, a thread is held up while the remote method executes is it the same case in the 2.0 framework? How does the CLR stop the GC from GCing the Thread object while it is sleeping and waiting for the remote method to complete?
Some async method calls run on another thread and some do not; it depends on the operation you are performing. This has not changed between .NET 1.x and 2.0. A Thread object always remains in memory while the thread is alive; this support is hard-coded into the CLR.
What's the difference between closures (in other languages) and anonymous methods?
Nothing really; they are the same concept. It’s just that C# supports this now.
