Dr. Dobb's Journal - October 2007 - (Page 35)

state, or filled with a simple pattern—usually all NULLs. On most modern platforms, virtual memory is committed at least a page at a time (for example, a page occupies four kilobytes of virtual memory on most versions of Windows). Pages of memory left uninitialized can be decommitted by any component in a process, and no harm results unless the committed memory is actually needed by the component that originally committed it. The same virtual memory analyzer/watchdog component that monitors reserved virtual memory may be extended to make software components smart enough to not die from an out-ofmemory condition whenever committed, uninitialized memory is available. The analysis can involve tracking the pages of memory as “in use” or “not in use.” One way to tell whether a page is in use is to run a compression routine, such as the LZW algorithm, on the contents of the page. This can be done for each page tracked by your analyzer/watchdog component when an out-of-memory condition occurs and when reserved, uncommitted pages are unavailable. When all or part of a page is found to be initialized, the page can be considered in use. The analysis can also involve recording a timestamp, during the run, each time virtual memory pages are commit- ted. When virtual memory runs low, your other components might need your analyzer/watchdog component to decommit the uninitialized page with the oldest timestamp, so that the page can be reused as needed to keep your program running. Figures 1–5 show a way you could design a simple virtual memory analyzer/watchdog component that helps your program stay alive, at least long enough to get some diagnostic information out, if not longer. The idea is to track virtual memory as the various components in your program reserve or commit it. For this to work, you need code that intercepts the system calls that are responsible for reserving, committing, and freeing virtual memory. On some operating systems, such as Linux, the choice of which calls to intercept is straightforward: On Linux, virtual memory regions are created via calls to mmap() and released via calls to munmap(). On other operating systems, such as Windows, there’s no documented API function that’s responsible for creating all of the virtual memory regions for use by your process. However, there is an API function, VirtualAlloc(), which you can use to create some regions. If you debug into VirtualAlloc(), you’ll reach an exported function that’s called for most, if not all, of the regions your program creates. On current versions of Windows, including Vista and XP, this function is called NtAllocateVirtualMemory(). This function Program is running Detect freeing of virtual memory region Update list of tracked virtual memory regions to indicate region is free Free tracked timestamp(s) and call chain, if any were recorded for the region Program continues running Figure 2 Program is running Detect reservation and/or commitment of virtual memory region Region was unreserved by our out-of-memory condition or exception handler? (see Figure 4) Yes Protect region from read/write access Record call chain associated with reservation/ commitment of stolen region Update entry in list of tracked virtual memory regions to tag region as stolen No Record new entry in list of tracked virtual memory regions Virtual memory is reserved but not committed? Yes Record timestamp for region as a whole No Record a set of timestamps, one associated with each page in the region Record call chain associated with original page reservation/commitment Record call chain associated with original page reservation/commitment Program continues running Figure 1 October 2007 l www.ddj.com l Dr. Dobb’s Journal 35 http://www.codejock.com http://www.codejock.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - October 2007

Cover Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook AI: It’s OK Again! Conversations Visual Cryptography and Bit-Plane Complexity Segmentation Inside the Windows Vista Disk Encryption Algorithm Memory-Aware Components Software and the Core Description Process Logging In C++ Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - October 2007

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.