Defrag Tools: #35 - CLR GC - Part 3

Play Defrag Tools: #35 - CLR GC - Part 3
Sign in to queue


In this episode of Defrag Tools, Andrew Richards, Maoni Stephens and Larry Larsen continue walking you through the CLR Garbage Collector. Maoni is the Principal developer for the GC on the CLR team.

Maoni's WebLog
Channel9 - CLR 4 Garbage Collector - Inside Background GC
Channel9 - CLR 4.5: Maoni Stephens - Server Background GC
MSDN Magazine - Investigating Memory Issues

[00:45] - Internal and Externals Roots
[05:55] - Start of GC: clr!WKS::GCHeap::GarbageCollectGeneration
[07:00] - !sos.dumpheap <heap start addr> <heap end addr>  (Range)
[07:30] - !sos.gcroot <addr>  (or !sos.gcwhere <addr>)
[09:45] - New Root Types? Dependent Handles (ConditionalWeakTable)
[12:32] - Handle Types
[13:30] - Pinned Handles - Effect on Fragmentation
[15:40] - Large Object Heap's Fragmentation & Coalescence
[17:55] - Pinned Objects
[19:33] - !sos.gchandles
[20:06] - !sos.gchandles -type Pinned
[20:45] - !sos.gchandles -type AsyncPinned



Right click to download this episode

The Discussion

  • User profile image

    Fantastic series on GC.  Practical memory leak advice, and an inside look into how the GC works. 

    I have a request though:  Is it possible to do another show (or point me to a blog article) that highlights pinning in a WinRT application a little more.  I've found that gcroot'ing memory leaks in WinRT does not necessarily give you as accurate a picture of what's keeping your objects in scope.   Sometimes the objects are pinned by large static object arrays, or sometimes they're just shown as pinned directly.  After some further code analysis it will reveal that the objects are in fact in scope due to application code, sometimes for  example from  async continuations.  An episode on unmasking root causes of memleaks in WinRT, and how it differs from .Net would be fantastic.

Add Your 2 Cents