Windows CE Memory Management

Memory ManagementIf you encounter the most important problem in writing a Windows CE program, it must be a memory problem. A wince system may only have 4 mb ram, which is very small compared to a PC, because the standard configuration of the PC has reached 128 MB or more. As a matter of fact, the memory of the machine running wince is very insufficient, so sometimes it is necessary to sacrifice the overall performance of the program to save memory when writing programs. Fortunately, although the memory of the wince system is small, the functions that can be used to manage the memory are perfect. Wince implements almost all Win32 Memory Management APIs available in Microsoft Windows XP and Microsoft Windows ME. Wince supports Virtual Memory Allocation, heaps (local) and separate), and memory ing files (memory-mapped files. Like Windows XP, WinCE supports a 32-bit flat address space with the memory protection function between applications. However, WinCE is designed for different applications, therefore, the underlying memory structure is different from that of Windows XP. These differences can affect how you design a wince application. In this chapter, I will describe the most basic wince memory structure. I will also describe the differences in available memory allocation methods in wince and how to use these different memory types to minimize the memory usage of your program. Memory BasicsFor all computers, running a wince system requires Rom (read-only memory) and RAM (random memory ). However, in the wince system, the usage of ROM and Ram is slightly different from that of personal computer environments. About RamRam is divided into two areas in the wince system: the first is the program memory, also known as the System Heap ). The second is the object store ). This object storage area is a bit like a permanent virtual RAM disk. Unlike the old-style virtual RAM disks on a PC, the objects stored in the OSS are retained even after the system is shut down. (Footnote) the reason for this arrangement is that the wince system, for example, the Pocket PC typically has a master battery and a backup battery. When you replace the primary battery, the Standby battery function is to provide power to ram to maintain the storage of files in the object storage area. After the user presses the restart key, the wince core starts to look for the object storage area established before the system is shut down. If it is found, it will continue to be used. Another region in Ram is used as the program storage zone. The program storage area is a bit like Ram in a PC, which saves heap and stack content for running applications. The line between the OSS and the OSS can be changed by moving it. You can find the setting to change the line in the control panel. When the available memory is low (low-memory, the system will pop up a dialog box asking if you want to divide the Object Storage Area ram into some program storage area Ram to meet the needs of the application to run. About RomIn a PC, Rom is used to store BIOS (Basic Input and Output System) and only-kb. In the wince system, the ROM size can be from 4 MB to 32 MB, and the entire operating system and applications bundled with the system are stored. In this case, Rom is like a read-only hard disk in the wince system. In a wince system, programs stored on ROM can be run in execute in place (xip) mode. In other words, the program can be executed directly from the ROM without being loaded to ram before execution. This capability has two major advantages for small systems. Code execution directly from Rom means that the program code does not occupy more valuable Ram. Similarly, the program does not need to be copied to ram before execution, so that it only takes a small amount of time to start an application. It is not in the Rom, but is included in the object storage area, only the nor flash memroy type pushed by Intel can be executed in xip mode. Rom is also a nor flash memory type) or flash memory card (flash memory storage card) programs in will not be executed in the field, they will be copied to Ram and then executed. About Virtual MemoryWince implements the virtual memory management of the system. In a virtual memory system, applications mainly process this separation (Note: physical separation may occur, but the system associates them ), virtual Address Space does not involve physical memory managed by hardware. The operating system uses the memory management unit of the microprocessor to process real-time conversion between virtual addresses and physical addresses. The advantage of this virtual memory method can be seen from the complex address space of MS-DOS systems. Once the requested Ram exceeds the 640-kb limit originally designed by the PC, the programmer will have to make plans like expanding the memory to increase the amount of available memory. OS/2 1.xand Windows 3.0 use a segment-based virtual memory system to solve the problem. Applications do not need to know the actual physical memory location when using virtual memory, as long as the memory is available. In these systems, the virtual memory is implemented in a segment, and the size of the memory block that can be moved (the segment is actually a memory block) ranges from 16 bytes to 64 KB. The limit of 64-kb is not due to the segment itself, but to the characteristics of Intel 80286. This is the segmented Virtual Memory System Structure of windows3.x and OS/21. X. Paging StorageIntel 80386 supports more than 64 kb segments, but Microsoft and IBM started to design OS/2 2.0. They chose a different virtual memory system and were subsequently supported by 386, this is a paging virtual memory system. In a paging storage system, the smallest unit that can be managed by the microprocessor is page ). For Windows NT and OS/2 2.0 systems, the page size is set to 386 processor's default 4096 bytes. When an application accesses a page, the microprocessor converts the virtual memory address of the page to the physical page in the actual Rom or RAM: this is the implementation of address ing and conversion, the virtual and the actual storage unit one-to-one correspondence), this page is also marked so that other programs access this page will be excluded. The operating system determines whether the Virtual Memory Page is valid. If it is valid, a ing of the physical memory page to the virtual page will be made. Wince implements a paging virtual memory system similar to other Win32 operating systems. In wince, the size of a page can be from 1024 bytes to 4096 bytes, depending on the microprocessor. This is different from Windows XP. Windows XP page size is 4096 bytes supported by Intel microprocessor. For CPU types supported by wince, Intel strong-arm and Hitachi sh4 both use 486-byte pages. NEC 4100 uses a 4-kb page size in Windows CE 3.0, but uses a 1-kb page size in earlier open systems. The virtual memory page can be in three states: free, reserved, or committed ),). A free page is as free and allocable as its name. The reserved page indicates that the virtual address has been retained and cannot be reallocated by other threads in the operating system or process. The reserved page cannot be used elsewhere, but it cannot be used by the current program because it is not mapped to the physical memory. To perform the ing, it must be submitted. A submission page can be retained by the application and mapped directly to the physical address. All the content I just described is outdated knowledge for experienced Win32 programmers. The most important thing for Windows CE programmers is to learn how Windows CE has changed these factors. When Windows CE implements most of the same memory API sets as its old brother Win32, the infrastructure under Windows CE will affect the above programs. Before looking at the memory structure of the window ce application, let's take a look at some functions that provide the global state of the system memory. Memory of the query systemIf an application knows the current memory status of the system, it can better manage available resources. Wince implements the getsysteminfo and globalmemorystatus functions of Win32. The prototype of the getsysteminfo function is void getsysteminfo (lpsystem_info lpsysteminfo). It passes a pointer to the system_info structure and is defined as follows:

The wprocessorarchitecture parameter indicates the architecture of the system microprocessor. Its value is defined in winnt. H, for example processor_ubunture_intel. Windows CE extends these constants, including processor_ubunture_arm, processor_ubunture_shx, and so on. The added constants include the network CPU (net CPU) supported by the Win32 operating system ). Skip some parameters. We can see that the dwprocessortype parameter comes from a specific microprocessor type. Constants include processor_hitachi_sh3 and processor_hitachi_sh4 In the Hitachi shx architecture. The last two parameters, wprocessorlevel and wprocessorrevision, indicate the characteristics of the CPU type. The wprocessorlevel parameter is similar to the dwprocessortype parameter, which is defined in a specified microprocessor series. dwprocessorrevision tells you the step level of the model and the chip ).

Typedef struct { Word wprocessorarchitecture; Word wreserved; DWORD dwpagesize; lpvoid sequence; DWORD dwprocessortype; DWORD sequence; Word wprocessorlevel; Word wprocessorrevision;} system_info;

The dwpagesize parameter specifies the page size of the microprocessor, in bytes. Knowing this value will make it easy for you to directly process the virtual memory API. Here I will only give a brief description. The lpminimumapplicationaddress and lpmaximumapplicationaddress parameters indicate the minimum and maximum virtual memory addresses available to the application. The dwactiveprocessormask and dwnumberofprocessors parameters show the number of processors supported by Windows XP. Because Windows CE only supports one processor, you can ignore this parameter. The dwallocationgranularity parameter specifies the limit for a complete virtual memory area allocation. For Windows XP, Windows CE sets the virtual zone to a limit of 64-kb, the system will also reserve a 64-kb virtual address space for it. This value is generally implemented by hardware code, but may vary with hardware values ). The second function is to conveniently detect the system status: void globalmemorystatus (lpmemorystatus lpmst );

It returns a memorystatus structure, defined

Typedef struct { DWORD dwlength; DWORD dwmemoryload; DWORD dwtotalphys; DWORD dwavailphys; DWORD dwtotalpagefile; DWORD dwavailpagefile; DWORD dwtotalvirtual; DWORD dwavailvirtual;} memorystatus;

The dwlength parameter must be initialized before calling this function. The dwmemoryload parameter is an uncertain value. This is an available general parameter that indicates the memory usage of the current system, specifies the usage of the physical memory ). The dwtotalphys and dwavailphys parameters indicate how many pages of RAM are allocated to the program storage zone ram, and how many other pages are available (Note: In bytes ). These values do not include Ram allocated to the OSS.

The dwtotalpagefile and dwavailpagefile parameters indicate the status of the current paging file in Windows XP and Windows ME. Because Windows CE does not support page files, these parameters are always 0. The dwtotalvirtual and dwavailvirtual parameters indicate the total and available number of virtual memory pages accessible to applications, dwavailvirtual refers to reserved and uncommitted memory ).

Use the information returned by globalmemorystatus to verify the Windows CE memory structure. Call the function on the HP ipaq Pocket PC with 32mbram. The returned value is as follows:

Dwmemoryload 0x18 (24) Dwtotalphys 0x011ac000 (18,530,304) dwavailphys 0x00b66000 (11,952,128) dwtotalpagefile 0 dwavailpagefile 0 dwtotalvirtual 0x02000000 (33,554,432) dwavailvirtual 0x01e10000 (31,522,816)

 

The dwtotalphys parameter table shows the system's 32 mb ram, which is allocated MB to the program storage area Ram, of which 12 Mb is still available. Note that for the application, it is not through this call that the other 14 mb ram is allocated to the object storage zone. To check the size of Ram allocated to the OSS, use getstoreinformation. The dwtotalpagefile and dwavailpagefile parameters are 0, indicating that the page file is not supported by Windows CE. The dwtotalvirtual parameter is very interesting because it shows the 32-MB virtual memory limit that Windows CE forces to the program. In the meantime, the dwavailvirtual parameter shows that only a small part of 32 MB virtual memory is used (Note: 33,554,432-31,522,816 = 2,031,616 ). Application address spaceAlthough similar to the Application Design of Windows XP, the address space of the Windows CE application has a huge difference that affects the application. Under Windows CE, an application is limited to 32 MB slot and 32 MB slot 1 in the virtual memory space, slot 1 is used to load xip-Based DLL. Windows CE divides the virtual address space into 33 slots, each of which is 32 MB and the serial number ranges from 0 to 32, c-2 ). When the system only has 4 mb ram, it seems reasonable to allocate 32 MB of virtual address space to the application. When Win32 programmers use this 2 GB virtual address space, remember the virtual address space limitations on Windows CE applications. Figure 7-1 shows the 64-MB virtual address space of an application, including 32 mb dll space for xip. Figure 7-1 memory ing of Windows CE note that the application is mapped from 0x10000 to a memory area of 64-kb, remember that the minimum 64 kB address space is reserved by windows for all applications. File images include code, static data segments, and resource segments. In the actual process, the code page is not loaded when the application starts. The code is loaded only when the page needs to be loaded. Read-only static data segments and read/write static data zones only occupy a small number of pages. These segments are arranged together. Like code, data segments are submitted to Ram only when they are read or written by applications. Application resources will be loaded into some separated pages. These resources are read-only and will be paged into Ram only when they are obtained by the application. The stack of the application is mapped to the resource segment. The stack segment location is easily located, because the pages it submits are at the end of the reserved area. Stack growth is from high address to low address (Note: Fill the address from high to low ). If the application has more than one thread, the application's address space will retain more than one stack segment. Next, the stack is the local heap ). The pilot program retains a large number of pages, about several hundred K for heap to use, but only submits the memory allocated by the malloc, new, localalloc function calls, only allocated memory can be submitted. unallocated memory cannot be used for submission ). The remaining reserved pages starting from the last part of the local heap to the non-xip dll will be mapped to free reserved space. If Ram permits, the application can submit these reserved pages. Non-xip DLLs is a DLL that cannot be executed in the Rom. It will be downloaded from the top to the 32 MB address space. Non-xip DLLs includes the DLL files compressed and stored in the Rom. Files in the compressed Rom must be decompressed before being loaded into RAM for execution. The high location of the 32 MB application address space reserved for xip DLLs. Windows CE maps the xip DLLs code into this space (Note: higher space), and The read/write segments are mapped to a lower location. Starting from Windows CE 4.2, the pure resource DLL in the Rom will be loaded into the virtual memory space other than 64 MB space of the application. In a mobile system such as pocketpc, when you press the close button, the system will not be actually shut down, and the system will be suspended in a low power consumption state. Different types of memory allocationA Windows CE application has many different memory allocation methods. At the bottom of the memory food chain is the virtualxxx function, which directly retains, submits, and releases (free) Virtual Memory pages. Next is the heap API. Heap is the memory area reserved by the system for applications. The Heap has two flavors: The local heap automatically assigned when the application starts, and the separate heap that can be manually created by the program ). Static data is generated after the heap API, and data blocks are defined by the compiler or manually created by the program. Finally, let's look at the stack. This is the region where the program stores variables for the function. A Windows CE does not support Win32 memory APIs, which are global heap APIs ). Global heap APIs include globalalloc, globalfree, and globalrealloc, which will not appear in Windows CE, it seems that Microsoft has not completely removed them ). The global heap is inherited only from the Win16 period of Windows 3.x. In Win32, all are similar to the local heap. A unique usage of global memory is to allocate memory for the Clipboard data, which has been replaced by the local heap and added with a handle in Windows CE. In Windows CE, the key to minimizing memory usage is to select an appropriate memory allocation policy that matches the memory block usage model. I will review these memory types and describe the minimum memory usage policy in the Windows CE application. Virtual MemoryVirtual Memory is the most basic memory type. The system calls the virtual memory API to allocate memory for other types of memory. Includes heap and stack. Virtual Memory APIs, including virtualalloc, virtualfree, and virtualresize functions, can directly operate on Virtual Memory pages in the virtual memory space of the application. The page can be retained, submitted to the physical memory, or released using these functions. Allocate virtual memory

Allocating and retaining virtual memory is the same as this function:

Lpvoid virtualalloc (lpvoid lpaddress, DWORD dwsize, DWORD flallocationtype, DWORD flprotect );

The first parameter of virtualalloc is the address of the memory area to be allocated. When you use virtualalloc to submit a previously reserved memory block, the lpaddress parameter can be used to identify the previously reserved memory block. If this parameter is null, the system determines the location of the allocated memory area and the size around the 64-kb range (Note: The minimum memory allocation size mentioned above ). The second parameter is dwsize, indicating the size of the region to be allocated or retained. This parameter is in bytes rather than pages. The system will distribute the parameter to the boundaries of the next page based on the size.

The flallocationtype parameter specifies the allocation type. You can specify or merge the following flags: mem_commit, mem_auto_commit, mem_reserve, and mem_top_down. Mem_commit indicates the memory used by the program. mem_reserve reserves the virtual address space for future submission. The reserved page cannot be accessed until the mem_commit flag is specified again when virtualalloc is called. The third flag, mem_top_down, tells the system to map applications from the maximum allowed virtual addresses. The mem_auto_commit flag is the only Windows CE most convenient flag. When this parameter is specified, the memory block is immediately retained. When the page is accessed for the first time, the system will automatically submit this page. This allows you to allocate large volumes of virtual memory without having to consider system and actual Ram allocation until the current page is used for the first time. The disadvantage of Automatic Memory submission is that physical Ram needs to return the page that may be unavailable when the page is accessed for the first time. In this case, the system generates an exception (exception ). Virtualalloc can submit part or all of a region by calling multiple times in parallel to reserve a large memory area. Submitting the same region for multiple calls will not cause failure. This allows an application to retain the memory and submit the pages to be written at will. When this method is not effective, it releases the application and checks the status of the page to see if it has been submitted before the call is submitted. The flprotect parameter specifies the access protection mode for the allocated area. These different flags are summarized in the following list: page_readonly this region is read-only. If the application attempts to access the page in the region, the access will be denied. The page_readwrite area can be read and written by applications. The page_execute area contains code that can be executed by the system. Operations that attempt to read and write to this region will be rejected. The page_execute_read area contains executable code, which can be read by applications. The page_execute_readwrite area contains executable code, which can be read and written by applications. When the page_guard area is accessed for the first time, a status_guard_page error occurs. This flag must be used together with other protection labels, indicating that the area is accessed for the first time. Page_noaccess is denied for any access to this region. When pages in page_nocacheram are mapped to this region, they are not cached by the microprocessor (cached ). The page_guard and page_nochache flags can be used together with other flags to further specify page features. The page_guard flag specifies a guard page, that is, when a page is submitted, a one-shot exception is generated due to the first access, and then the specified access permission is obtained. Page_nocache prevents it from being cached by the microprocessor when mapped to a virtual page. This sign allows device drivers to use Direct Memory Access (DMA) to share memory blocks.