MSDN Magazine - June 2008 - (Page 15)

MaOni StepHenS CLR InsIde Out Large Object Heap Uncovered The CLR garbage collector (GC) divides objects into small and large categories. When an object is large, some attributes associated with it become more significant than if the object is small. For instance, compacting it—copying the memory elsewhere on the heap—is expensive. In this month’s column I am going to look at the large object heap in depth. I will talk about what qualifies an object as a large object, how these large objects are collected, and what kind of performance implications large objects impose. The Large Object Heap and the GC In the Microsoft® .NET Framework 1.1 and 2.0, if an object is greater than or equal to 85,000 bytes it’s considered a large object. This number was determined as a result of performance tuning. When an object allocation request comes in and meets that size threshold, it will be allocated on the large object heap. What does this mean exactly? To understand this, it may be beneficial to explain some fundamentals about the .NET garbage collector. As many of you are aware, the .NET garbage collector is a generational collector. It has three generations: generation 0, generation 1, and generation 2. The reason for this is so that in a well-tuned application, you can expect most objects to die in generation 0. For example, in a server app, the allocations associated with each request should die after the request is finished. The in-flight allocation requests will make it into generation 1 and die there. Essentially, generation 1 acts as a buffer between young object areas and long-lived object areas. From a generation point of view, large objects belong to generation 2 because they are collected only when there is a generation 2 collection. When a generation is collected, all younger generations are also collected. So for example, when a generation 1 garbage collection happens, both generation 1 and 0 are collected. And when a generation 2 garbage collection happens, the whole heap is collected. For this reason, a generation 2 garbage collection is also known as a full garbage collection. In this column I will use the term generation 2 garbage collection instead of full garbage collection, but they are interchangeable. Generations are the logical view of the garbage collector heap. When a generation two garbage collection happens, the whole heap is collected. that’s a full garbage collection. Physically, objects live on managed heap segments. A managed heap segment is a chunk of memory that the garbage collector reserves from the OS (via calling VirtualAlloc) on behalf of managed code. When the CLR is loaded, two initial heap segments are allocated—one for small objects and one for large objects, which I will refer to as the small object heap (SOH) and the large object heap (LOH), respectively. Allocation requests are then satisfied by putting managed objects on one of these managed heap segments. If the object is less than 85,000 bytes, it will be put on a SOH segment; otherwise it’ll be on a LOH segment. Segments are committed (in smaller chunks) as more and more objects are allocated onto them. For the SOH, objects that survive a garbage collection are promoted to the next generation; so objects that survive a generation 0 collection will be considered generation 1 objects, and so on. Objects that survive the oldest generation, however, will still be considered in the oldest generation. In other words, survivors from generation 2 will be generation 2 objects; and survivors from LOH will be LOH objects (collected with generation 2). User code can only allocate in generation 0 (small objects) or LOH (large objects). Only the garbage collector can “allocate” objects in generation 1 (by promoting survivors from generation 0) and generation 2 (by promoting survivors from generations 1 and 2). When a garbage collection is triggered, the garbage collector traces through the live objects and compacts them. For LOH, though, because compaction is expensive the CLR team chose to sweep them, making a free list out of dead objects that can be reused later to satisfy large object allocation requests. Adjacent dead objects are made into one free object. An important thing to keep in mind is that even though today we don’t compact LOH, we might in the future. So if you allocate large objects and want to make sure they don’t move, you should still pin them. Note that the figures shown here are only for illustration purSend your questions and comments to clrinout@microsoft.com. June 2008 15

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.