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

State of the Art MEMORY-AWARE COMPONENTS reserved or committed for some other purpose, then you need a way to tell one component from another. A simple way to do this is based on call chains. Each component itself occupies a region, or a set of regions, where it’s loaded in virtual memory. Your watchdog may track those regions along with all the others. If so, then comparing the base addresses of the regions associated with components is a matter of a lookup in your region list. Better yet, you can call an API function, such as GetModuleHandle() on Windows, to find the base address of each module that appears along the call chain. Your watchdog needs to be able to recognize calls into modules that represent API code or allocator code, so that it won’t compare the modules containing this code. Doing so confuses it, making it fail to recognize call chains coming from different components. Because many components share a common allocator, the call chains associated with region creation typically end up in the same few functions. That’s why you can’t tell components apart by the last few entries of a call chain associated with region cre- ation. But if you’ll spend some time debugging your tracking code, particularly in the routine that implements Figure 1, then you get to know where common region creation code lies in virtual memory. By ruling out these ranges during call-chain comparison and instead looking to the next caller beyond one of these common routines for any given chain, you can get an idea of whether the component responsible for stealing a region is the same component that is now accessing it. If so, then your watchdog can safely unprotect the region and go ahead with the access. Otherwise, the time has evidently arrived to steal another region. An obvious benefit of this region tracking/stealing scheme is the ability to construct a detailed report when an out-ofmemory condition arises. Often, when a program runs out of memory, it can’t even do so much as complain before the inevitable crash occurs. The technique of making available any unused virtual memory for use in constructing and displaying diagnostic output can be very useful in and of itself. The added ability to provide information about the virtual memory regions that are being used, including information about which components created them and when they were created, can provide the clues you need to prevent similar out-ofmemory conditions down the road. You don’t need to implement a componentrecognition scheme to realize this benefit, if you’re happy enough to get your diagnostic output and to let the program crash. But if you want to keep your program alive longer, you will probably want to clean up any virtual memory committed for diagnostic purposes as soon as you can after making your diagnostic information available. Of course, the watchdog component itself adds to your program’s memory footprint, but only modestly. The entire watchdog module can contain perhaps 3–5 times the amount of code in Listings One through Three. The tracking data for virtual memory regions is minimal, because there are typically not more than several hundred regions to track, even for a large and complex program. Plenty of components, even commercial ones such as some JVMs, leave large amounts of virtual 38 Dr. Dobb’s Journal l www.ddj.com l October 2007 http://www.leadtools.com http://www.leadtools.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.