MSDN Magazine - June 2008 - (Page 16)

Figure 1 SOH Allocations and Garbage Collections poses. I used very few objects, just to show what happens on the heap. In reality there are many more objects there. Figure 1 illustrates a scenario where I form generation 1 after the first generation 0 GC where Obj1 and Obj3 are dead; and I form generation 2 after the first generation 1 GC where Obj2 and Obj5 are dead. Figure 2 illustrates that after a generation 2 garbage collection in which you saw that Obj1 and Obj2 were dead, I formed one free space out of the memory that used to be occupied by Obj1 and Obj2, OS (by calling VirtualFree). Memory from the last live object to the end of the segment is decommitted. And the free spaces remain committed though they are reset, meaning the OS doesn’t need to write data in them back to disk. Figure 3 illustrates a scenario in which I release a segment back to the OS (segment 2) and decommit more space on the remaining segments. If I need to use the decommitted space at the end of the segment to satisfy new large object allocation requests, I will commit the memory again. For an explanation on commit/decommit, please see the MSDN® documentation on VirtualAlloc at go.microsoft.com/ fwlink/?LinkId=116041. .net memory counters are a good place to start when you have performance issues. which then was used to satisfy the allocation request for Obj4. The space after the last object Obj3 until the end of the segment can still be used to satisfy further allocation requests. If I don’t have enough free space to accommodate the large object allocation requests, I will first attempt to acquire more segments from the OS. If that fails, then I will trigger a generation 2 garbage collection in hope of freeing up some space. During a generation 2 garbage collection, I take the opportunity to release segments that have no live objects on them back to the When a Large Object Gets Collected To determine when a large object is collected, let’s first talk about when a garbage collection happens in general. A garbage collection occurs if one of the following conditions happens: Allocation Exceeds the Generation 0 or Large Object Threshold Most GCs happen because of allocations on the managed heap (this is the most typical case). System.GC.Collect Is Called When someone calls GC.Collect on generation 2 (by passing either no arguments to GC.Collect or passing GC.MaxGeneration as an argument), the LOH will get collected right away along with the rest of the managed heap. System Is in Low Memory Situation This happens when I receive the high memory notification from the OS. If I think doing a generation 2 GC will be productive, I will trigger one. The threshold is a property of each generation. When you allocate objects into a generation, you increase the amount of memory in that generation and get closer to the generation’s threshold. And when the threshold is exceeded for a generation, a garbage collection is triggered on that generation. So when you allocate small or large objects, you consume generation 0’s and LOH’s respective thresholds. And when the garbage collector allocates into generation 1 and 2, it consumes generation 1 thresholds. These thresholds are dynamically tuned as the program runs. LOH Performance Implications Figure 2 LOH Allocations and Garbage Collections 16 msdn magazine Let’s look at allocation costs. The CLR makes the guarantee that the memory for every new object I give out is cleared. This means the allocation cost of a large object is completely dominated by memory clearing (unless it triggers a garbage collection). If it takes two cycles to clear 1 byte, it means it takes 170,000 cycles to clear CLR inside Out http://go.microsoft.com/fwlink/?LinkId=116041 http://go.microsoft.com/fwlink/?LinkId=116041

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.