Device Memory Management in the .NET Compact Framework
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]
An important strength of the .NET Compact Framework is efficient resource usage, especially volatile RAM. Devices are not required to have hardware memory management units (MMU) or operating system virtual memory.
For the .NET Compact Framework version 3.5, see the section describing CAB File installation. .NET Compact Framework version 3.5 is not yet available in ROM.
For the .NET Compact Framework version 2.0, the storage size is as follows:
5.5 MB (ROM), uncompressed, on Windows Mobile 5.0.
Persistent storage is no longer compressed starting with Windows Mobile 5.0.
For the .NET Compact Framework version 1.0, the storage size is as follows:
1.55 MB (ROM), compressed, on Pocket PC 2000 and 2002.
1.35 MB (ROM), compressed, on Windows Mobile 2003 for Pocket PC and Windows Mobile 2003 for Smartphone.
Running RAM requirements:
0.5 MB+ (depends on application).
Typical application sizes:
During the installation of the .NET Compact Framework version 2.0 Service Pack 1 and later versions, you are prompted to install either to the device or to a storage card if present. If you elect to install to storage, the global assembly cache is placed on a storage card and the files for the common language runtime (CLR) are placed in the \Windows directory. In the .NET Compact Framework version 3.5, the global assembly cache requires approximately 5.2 MB of space, and the CLR requires 1.3 MB.
The performance of the .NET Compact Framework varies for the CAB file installation depending on the memory implementation in hardware and software. For some devices, better performance can be achieved by installing the global assembly cache to a storage card.
The .NET Compact Frameworkk is designed to operate optimally on systems that have the following characteristics:
Approximately 5 to 10 times the flash memory or RAM file system capacity to store the .NET Compact Framework and its applications in dynamic RAM (DRAM).
A working space from as small as 128 KB to 1 MB in DRAM.
An optional hard drive.
The .NET Compact Framework uses available system memory carefully. No RAM is accessed until you run an application. Moreover, the .NET Compact Framework frees the RAM when you quit programs. The native operating system is not required to have its own memory protection capabilities. Exceptions are always thrown when memory that is not owned is accessed.
When memory is scarce, the .NET Compact Framework aggressively releases internal data structures that are not needed by the currently executing code. Therefore, the program can continue running, even in low-memory situations. If the application requires more memory than is available, the .NET Compact Framework closes the application cleanly and releases all underlying resources. The .NET Compact Framework itself should not fail because of low memory.
The application domain host starts .NET Compact Framework applications and the common language runtime. .NET Compact Framework applications use code space and static and dynamic data space in the same manner as native applications. When no .NET Compact Framework applications are running, there is no RAM cost beyond the application domain host, and a small amount of static data is used by the common language runtime. Windows CE .NET creates an application domain host when a .NET Compact Framework application is started.
.NET Compact Framework applications are packaged into .exe files and .dll files, which can be stored in a read-only or read/write file system in flash (or ROM for read-only). The common language runtime class loader can read these files in directly addressable blocks without making a memory copy and without requiring a memory management unit to create a memory-mapped view of the file.
Developers are encouraged to test applications on multiple devices to understand device-specific variances in performance.
Random access memory (RAM) is used to store dynamic data structures and JIT-compiled code. The .NET Compact Framework uses available RAM, up to a limit specified by the device, to cache generated code and data structures and then frees the memory when appropriate.
The common language runtime uses a code-pitching technique to free blocks of JIT-compiled code at run time when memory is low. This enables larger programs to run on RAM-constrained systems with minimal performance penalty.
Native code that forms the common language runtime can reside in read-only memory (ROM) or a RAM file system. The .NET Compact Framework uses available ROM, flash, or disk storage to enable applications to continue to run with lower performance in low-memory situations.
Files that contain Microsoft intermediate language (MSIL) instructions and metadata for class libraries are stored in either a ROM file system or a RAM file system. Class libraries can be downloaded into a read/write file system as part of the downloadable application installation process.