Steven Pratschner's .Net CF WebLog : GC

Using the .NetCF Remote Performance Monitor to find memory leaks: A real world example

stevenpr — Fri, 23 Mar 2007 20:32:00 GMT

A few weeks ago I posted an entry describing how to use the .Net Compact Framework Remote Performance Monitor to find managed memory leaks. The other day I ran across a post from Rabi Satter describing how he used to tool to solve a critical leak for one of his customers. His real world experience provides a much more complete memory leak example than my original post did. Check it out: . http://www.satter.org/2007/03/thank_god_for_c.html

Thanks,

Steven

This posting is provided "AS IS" with no warranties, and confers no rights.

Using the .Net Compact Framework Remote Performance Monitor to Optimize your application's memory usage

stevenpr — Wed, 03 Jan 2007 02:51:00 GMT

The November issue of .Net Developers Journal includes a new article on using the Remote Performance Montior. In the article I describe how to interpret the various memory-related counters to optimize how your Compact Framework application uses memory on the device.

Thanks,

Steven

This posting is provided "AS IS" with no warranties, and confers no rights.

.Net Compact Framework GC article in .Net Developers Journal

stevenpr — Thu, 09 Feb 2006 04:23:00 GMT

I recently wrote an article for .Net Developers Journal on how operations like boxing and string manipulations can affect the performance of the Compact Framework's garbage collector. Credit for the ideas and samples in the article go to Roman Batoukov.

Check out the February issue.

For more Compact Framework performance information, see the FAQ on our team blog.

Thanks,
Steven

The Design of the .Net Compact Framework CLR, Part III: GC Heap Management

stevenpr — Thu, 15 Dec 2005 02:31:00 GMT

Here's Part III of the series on the design of the .Net Compact Framework CLR. Previous posts in this series provided an overview of how the CLR manages memory and described the basic design tenants of the JIT compilers:

Part I, Overview and Background

Part II, Jit Compiler Design Considerations

This post focuses on the design of the garbage collector from the perspective of how the GC heap is managed.

---------

Garbage collection is typically the topic that first comes to mind when discussing how memory is managed on the .Net platform. Not surprisingly, the Compact Framework’s garbage collector differs in many respects from its desktop counterpart due to the constraints in which it must run. Like most other subsystems within the Compact Framework CLR, the garbage collector has been designed to free all the memory it can when the amount of memory available on the device is low.

At a high level, the GC performs two basic functions: it allocates memory to hold instances of reference types and it collects the instances that are no longer needed.

Allocating Reference Types

As described in Part 1, the GC heap lives in the per-application 32 MB virtual address space. As with the JIT heap, the GC heap starts small and grows incrementally as more space is needed. However, there are two important differences in the way the GC heap grows when compared to the JIT heap: the GC heap grows in fixed increments, and it does not grow unbounded.

The growth increment for the GC heap is generally 64K. When a new 64K “segment” is created, allocations occur from that segment until no more room is available, at which point another segment is created. The Compact Framework GC allocates new segments using the standard Win32 API VirtualAlloc. Allocations within a segment are very fast. Performance tests on version 2 of the .Net Compact Framework show that the allocator can create up to 7.5 million instances of a small reference type per second. The allocator is so fast because the algorithm it uses is simple. A pointer is maintained to the “next available location” in the GC heap. To allocate space for a new instance, the allocator simply moves the pointer by the number of bytes needed to hold the object as shown in Figure 4:

Figure 4
Allocating a new reference type is simply a matter of adjusting the “next object” pointer.

While the default growth increment for the GC heap is 64K, the allocator will grow the heap in larger increments to accommodate objects greater than 64K. For example, if a program attempts to create an object that is 70k, the allocator will create a new segment of that size to store the larger object.

The GC heap grows in increments as described until it reaches 1 MB, at which point a collection begins (more on this later). The GC heap may continue to grow after that, but a collection occurs whenever 1MB of objects has been allocated since the last collection occurred.

Collecting Reference Types

Now that we’ve seen how the GC heap grows, let’s take a look at how it shrinks. Again, the ability to reduce the size of the GC heap under memory pressure is key to helping applications run well on memory constrained devices. In this section, we’ll look at what causes a collection to occur and when memory is freed and returned to the operating system.

There are several triggers that can cause a garbage collection to occur. As described, one of those triggers is the allocation of 1MB of managed objects. Other triggers include resource failures such as the inability to allocate more memory, create more window handles and so on. See An Overview of the .Net Compact Framework Garbage Collector for more details on what triggers a collection.

Memory is not freed and returned to the operating system every time a GC occurs. To understand when memory is freed from the operating system’s perspective, let’s take a closer look at what happens when the collector runs.

Unreferenced Objects

During every collection, the GC looks through the heap to find objects that are no longer referenced. The memory for these unneeded objects is freed in the sense that more space is now available in the GC heap. After freeing the unreferenced types, it’s possible that some number of 64K segments may be completely empty. If a segment is completely empty, and the GC still has 1MB of allocated segments, the empty 64K segments will be returned to the operating system by calling VirtualFree. With the exception of a “full” GC (described below), the collector always keeps a 1MB cache of 64K segments, even if some of them are empty. By caching segments in this way, performance is improved by reducing the number of calls to VirtualAlloc and VirtualFree.

Compacting the GC Heap

The GC may optionally compact the heap during a collection. When the heap reaches a state where it is sufficiently fragmented, the collector “compacts” the heap by moving all live objects close to each other. The primary goal in compacting the heap is to make larger blocks of memory available in which to allocate more objects. Figure 5 represents the contents of a GC heap before and after compaction.

Figure 5
The contents of a sample GC heap before and after compaction

As with the “simple” object collection, the GC will return empty 64K segments to the operating system as long as the 1MB segment cache is full.

A "Full" GC

Under the normal course of events, the GC works as described above: periodic collections are made after every 1MB of allocations, the heap is compacted if it gets too fragmented, and empty segments are returned to the operating system as long as the collector’s 1 MB cache is full.

There three scenarios, however, in which more drastic steps are taken to make more memory available. These scenarios align exactly with the times at which the JIT reduces the size of it’s heap as described in Part II: when a failure to allocate memory or other resource occurs, when an application is moved to the background, or when an application receives the WM_HIBERNATE message from the operating system. At these times, the GC will hot hold onto its 1MB segment cache. It will collect all unreferenced objects, compact the heap, and free any memory it can.

Pulling it All Together

Now that we’ve seen how the GC allocates and frees memory, let’s look at the size of the GC heap over the lifetime of an application.

Figure 6

The size of the GC heap over the lifetime of an application.

The graph in Figure 6 tracks two pieces of data. The yellow line shows the cumulative number of bytes the garbage collector has been asked to allocate over the lifetime of the application. This number will continue to grow without bounds as long as the application continues to allocate new objects.

The blue line in Figure 6 shows the size of the GC heap over time. There are several points worth noting. First, when the application starts and continues to run, we see the size of the GC heap growing in a consistent stair-step fashion. Each “step” in the graph corresponds to a newly created 64K GC segment. Second, we can see that the blue line levels off after some time. As you’d expect from the earlier description of the allocation and collection algorithms, the point at which the size of the heap flattens out is at 1MB. Next, you can see a dramatic drop in the size of the heap. In this case, the drop occurs when I moved the application I was monitoring into the background. After the application switches to the foreground, we start to see the heap growing in 64K chunks again.

This series of posts has now covered the basics of how the .Net Compact Framework managed memory, and the design decisions made while building the JIT compilers and the garbage collector. In my next post, I’ll look at how the need to run efficiently on memory constrained devices has affected the design of the CLR’s class loader.

This posting is provided "AS IS" with no warranties, and confers no rights.

An Overview of the .Net Compact Framework Garbage Collector

stevenpr — Mon, 26 Jul 2004 21:18:00 GMT

Developers frequently ask for more information about how the garbage collector works in the Compact Framework. In this blog entry, I’ll address the questions we are most often asked about the collector. I’ll start by describing the overall model for collections in the Compact Framework. I’ll then point out a few of the key differences between how collections are done in the Compact Framework and the full .Net Framework. If you have questions I don’t answer, feel free to send me mail or comment on this entry and I’ll work to get them addressed in the future.

Collection Model

Let’s start by looking at the collection model used by the Compact Framework. In this section, I’ll describe the conditions that cause a collection to occur and the specific steps taken each time the collector runs.

A collection is initiated when either:

· 1MB of objects have been allocated,

· An application is moved to the background,

· A failure to allocate memory occurs

· An application calls GC.Collect (more on this later).

When doing a collection, the Compact CLR performs the following steps:

1. Brings all threads to a “safe point”. Before a collection can occur, the CLR must ensure that all threads are in a “known” state with respect to the GC heap. That is, no threads are in a state in which they can alter the GC heap in any way once a collection begins. To do this, the CLR brings all threads to a state where they are not executing any managed code, nor are they running in the unmanaged portion of the CLR. Once they reach a safe point, threads are not allowed to proceed until the collection has finished (except for the thread that actually does the collection, that is).

2. Marks all objects that descend from live roots. Once all threads have reached a safe point, the objects in the GC heap are examined. Those that descend from live roots, such as local variables in the current scope, statics and so on are marked. Note that there is not a special thread that exists solely to do garbage collections. The thread that was running when the GC was triggered is the thread that does the collection.

3. Frees all unmarked objects and populates the finalization queue. The memory for all unmarked objects that don’t have finalizers is freed. Those unmarked objects that do have finalizers are placed on a list known as the finalization queue.

4. Occasionally, compacts the GC heap. If the CLR determines that the GC heap is sufficiently fragmented, the heap is compacted. The heuristic used to determine when a compaction should occur is currently based on the percentage of fragmentation in the heap, but different heuristics may be used in future releases.

5. “Pitches” Jitted code in some scenarios. The Compact Framework CLR maintains jitted code in an in-memory cache. Instead of recompiling a method each time it is called, the native code for that method is simply retrieved from the cache. When a failure to allocate memory occurs, or when an application is moved to the background, the contents of the code cache are freed, or “pitched”, to make more memory available to the system.

6. Runs the finalizers for all objects on the finalization queue. After the unused objects are freed and the optional compacting and code pitching occurs, the collection is considered done and all threads are allowed to resume. In the background, the CLR uses a dedicated thread to run the finalizers for all objects on the finalization queue. Those objects are then freed the next time a collection occurs.

How is the NetCF collector different from the collector in the Full .Net Framework?

The Compact Framework targets significantly different scenarios than the full .Net Framework does. While the Compact Framework is tuned specifically for use on devices with limited resources, the full .Net Framework supports scenarios ranging from client side UI applications to server side applications such as SQL Server and ASP.Net that may run on machines with multiple processors. As such, it’s natural to find significant differences between the Compact Framework’s garbage collector and the garbage collector provided by the full .Net Framework. The primary differences between the two collectors are:

Different basic collection model. As we’ve seen, the .Net CF has a standard mark and sweep collection model augmented with occasional compaction and code pitching. While the high level goal (to reclaim memory allocated to objects that are no longer used) is the same, the basic collection model on the full .Net Framework is substantially different. In particular, the full .Net Framework uses a “generational” model whereby objects that survive collections are promoted to higher generations that are collected less frequently. In this way, the collector on the full .Net Framework tunes itself such that less time is spent analyzing objects that aren’t likely to be collected anyway. There are other differences as well. For example, the full .Net Framework handles unusually large objects differently than normal objects and the events that cause a GC to occur are different. Chapter 19 in Jeff Richter’s “Applied .Net Framework Programming” book provides a thorough, yet easily readable description of how garbage collection works on the full .Net Framework.

Fewer GC “configurations”. Because the full .Net Framework supports such a wide variety of application scenarios, its garbage collector is able to run in different “modes” specifically tuned by scenario. In particular, the collection strategy used by the full .Net Framework is different depending on whether you are running an interactive application on a work station vs. a server application with high throughput requirements on a multi processor machine. You’ve probably heard these referred to as “workstation” vs. “server” garbage collection. Also, the workstation flavor of garbage collection has a concurrent mode in which the collector uses threads differently in an attempt to keep the application’s user interface as responsive as possible. The Compact Framework supports none of these different GC modes. Because the range of application scenarios is smaller, and the collector itself must be smaller, a single collection model is used regardless of the type of device your application is running on.

Code pitching. As described, the Compact Framework’s collector frees code it has previously jitted in order to free memory in certain scenarios. The collector on the full .Net Framework has no such “code pitching” capability – the amount of jitted code kept in memory is free to grow without bounds.

Steven Pratschner's .Net CF WebLog : GC

Using the .NetCF Remote Performance Monitor to find memory leaks: A real world example

Using the .Net Compact Framework Remote Performance Monitor to Optimize your application's memory usage

.Net Compact Framework GC article in .Net Developers Journal

The Design of the .Net Compact Framework CLR, Part III: GC Heap Management

Allocating Reference Types

Collecting Reference Types

Unreferenced Objects

Compacting the GC Heap

A "Full" GC

Pulling it All Together

An Overview of the .Net Compact Framework Garbage Collector

Collection Model

How is the NetCF collector different from the collector in the Full .Net Framework?

Other Frequently Asked Questions