In the February issue of .NET Developers Journal, I described how implicit operations such as the boxing of value types can dramatically increase the amount of memory your .NET Compact Framework application uses. At the time, the tools available to help you get a picture of how your application uses memory were very limited. While version 2 of the Compact Framework did report performance statistics, it did so only when your application closed. The static nature of these counters made it very hard to locate memory usage trends in your application.

What's needed instead is a tool that allows you to graphically view how your application is using memory while it's running. Fortunately, Service Pack 1 of .NET Compact Framework version 2.0 provides such a tool: the .NET Compact Framework Remote Performance Monitor (RPM). In this article, I'll show you how to use the RPM to determine your application's peak working set and to help you identify allocation trends in your application that can be optimized to use memory more efficiently.

Let's get started by taking a look at how the .NET Compact Framework manages memory as your application is running.

.NET Compact Framework Memory Management Basics
The .NET Compact Framework CLR has been tuned over time to make optimal use of the device's memory on behalf of the running application. A basic understanding of how the Compact Framework uses memory provides essential background that we'll use later when we discuss how to use the RPM. As your application is running, the CLR makes numerous memory allocations to support the basic runtime services your application needs. Many of these are allocations you'd expect, such as the memory that's allocated in the garbage collection heap each time your application creates an instance of a reference type using the new keyword.

The need for other types of allocations isn't always so clear. For example, the CLR allocates various "bookkeeping" data that it uses internally. These internal data structures are used to track which classes have been loaded, which methods are in those classes, whether those methods have been JIT-compiled, and so on. I've grouped the allocations made by the CLR into the following 5 categories:

• Application and class library assemblies: The CLR loads all of the IL code and metadata for both the application itself and the .NET Compact Framework class libraries. The IL is clearly needed so the JIT compiler can generate executable native code, while the metadata is used by the CLR class loader to create some of the internal bookkeeping data structures I referred to earlier.
• JIT-compiled native code: As an application is executing, the JIT compiler is called upon to generate the native code for each method that is accessed. This native code is stored in a dedicated heap that can grow and shrink depending on memory pressure.
• Allocated reference types: Even the simplest managed applications allocate reference types. These types are typically created with language keywords such as new in C# or Visual Basic.NET. A basic "Hello, World" application will cause instances of types including forms, menus, controls, and strings to be created. In addition, instances of application-specific types are often created as well. The memory for all reference types comes from the garbage collector's heap.
• In-memory representation of type metadata: As classes and their methods are needed during the execution of a program, the CLR reads their metadata and generates a set of data structures used to track the state of a running program.
• Miscellaneous allocations: In addition to the categories of allocations described above, the CLR generates a small amount of additional data as it runs an application. Data in this category includes stubs that the JIT compiler uses to determine whether a method has been compiled.

To get a complete view of all the memory required to run an application, we must also consider the memory needed to hold the code for the .NET Compact Framework CLR. The CLR consists of two DLLs: mscoree.dll and mscoree2_0.dll. These DLLs, along with the native portion of the Compact Framework's Windows Forms implementation, netcfagl2_0.dll, are loaded by WindowsCE the first time a managed application is run.

Not all of the allocations described above are of equal importance when analyzing memory issues with device applications. Some categories of allocations are more critical to monitor than others because of the way the Compact Framework uses the WindowsCE memory model. There are two important axes to consider: 1) whether a given category of allocations is shared among all applications or is specific to a given application, and 2) whether the memory used for a given set of allocations can be paged by WindowsCE when the device is under memory pressure or not.

WindowsCE provides three general memory areas, as shown in Figure 1:

• System Code Space: The read-only code pages for all system DLLs, such as coredll.dll, are loaded into this space. There is one system code space per device so all applications share the code pages for the system DLLs. Windows CE can page portions of this memory to storage and pull them back later if needed.
• Per-Process Address Space: There are two primary reasons that device applications encounter memory issues on WindowsCE. First, the virtual address space WindowsCE provides to each application is only 32MB. Second, the data stored in this per-process space cannot be paged out under memory pressure. The stack for each thread in the application, the code pages for the application's executable files (if it contains native DLLs), and any per-application heaps are examples of data elements stored in this space.
• High Memory Area: The 1GB high memory area provides virtual address space from which requests for large amounts of virtual memory can be satisfied. Large memory allocations and all memory mapped files are stored in high memory. All data stored in the high memory area is visible to applications on the device. Windows CE can swap pages from the high memory area to storage and back if needed.

Because the per-process address space is relatively small, and because its contents cannot be paged, making efficient use of the per-process space is the best way to ensure your application behaves well on memory constrained devices. Figure 2 shows that the garbage collection heap, the JITted code heap and the heaps used to store the CLR runtime data structures, and other temporary allocations are stored in the per-process address space.

Now that we know where to look, let's see how the RPM allows us to graphically see how the various CLR heaps stored in the per-process space grow and shrink as an application runs.

Using the .NET Compact Framework Remote Performance Monitor Memory Management Counters
If you've spent much time debugging .NET Compact Framework applications, you may be familiar with the performance statistics contained in ".stat" files. By setting a registry key, you can direct the Compact Framework to write a variety of performance data into a text file with a .stat extension after your application closes (see http://blogs.msdn.com/davidklinems/archive/2005/12/09/502125.aspx for more details). The Remote Performance Monitor tool introduced in version 2 Service Pack 1 of the Compact Framework is a GUI application that runs on your Windows desktop machine and displays performance data from an application running on a device. The data displayed by RPM is the same data contained in the .stat files. However, RPM makes performance analysis much easier because the data is updated and displayed continually while the application is running.

After installing the RPM (see the sidebar "Installing the Remote Performance Monitor"), you can view dynamic performance statistics for your application by launching netcfrpm.exe from your Windows machine and selecting the "Live Counters...." option under the File menu. Doing so displays the window shown in Figure 3.

When connected via ActiveSync, your device will automatically show up in the "Device" dropdown on RPM's main form. (If you aren't using ActiveSync you must enter the IP address of your device in the "Device" dropdown. You can get your IP address by running netcflaunch.exe from the \windows directory on your device.) After selecting your device, type the fully qualified name of the application you'd like to launch in the "Application" text box and select the "Connect" button.

After RPM connects to your device and launches your application, several performance statistics will be displayed in a grid on RPM's main form, as shown in Figure 4.

These statistics are grouped by category. There are categories for most functional areas of the CLR including native code interoperability, class loading, and generics. The counters we are most interested in are those in the "Memory" and "GC" categories. I'll briefly describe the counters here and will discuss how to use the counters to perform more extensive analysis later in the section entitled "Analyzing the Data". The following counters in the Memory category are used to view the size of the 5 per-process heaps created by the CLR:

• AppDomain heap: The CLR data structures that represent the loaded assemblies and classes are kept in this heap. The AppDomain heap is unique in that it never shrinks. It will grow as long as the application continues to load types, and it's only freed when the application exits.
• GC heap: Most of the action in a managed application occurs in the GC heap. Fortunately, the NetCF GC is optimized to shrink the heap and return memory to WindowsCE when needed. Even so, the amount of activity within the GC heap is a good indicator of the overall efficiency of your application.
• JIT heap: The native machine instructions produced by the JIT compiler are stored in the JIT heap. The JIT heap will grow until the application experiences memory pressure or is moved to the background, at which point the CLR shrinks the heap as much as it can without disrupting the execution of the application.
• Process heap and Short Term heap: The various other allocations made by the CLR are stored in either the Process heap or the Short Term heap. Both of these heaps are typically small and have little, if any, impact on performance.

The GC category includes numerous counters used to view the workings of the GC. I've found the following counters particularly useful:

• Garbage Collections: The number of times the garbage collector has run.
• GC Latency Time: The amount of time spent in the garbage collector. Both the total time and the average time per collection are reported.
• Bytes Collected by GC: The number of bytes collected by the GC. Both the total number of bytes and the average number of bytes collected each time the GC ran are reported.
• Objects Finalized: The number of objects that had finalizers to run.
• Managed Objects Allocated: The number of objects allocated as your application ran.
• Boxed Value Types: The number of value types that were boxed. This number will always be a subset of Managed Objects Allocated.
• Managed String Objects Allocated: The number of string objects allocated. This number will also always be a subset of Managed Objects Allocated. In addition to displaying the data in the grid, RPM is also integrated with the standard Windows Performance Monitor so you can view the performance data graphically. Each performance category reported by RPM shows up as a performance object in Windows Performance Monitor, as shown in Figure 5.