Dr. Dobb's Journal - January 2008 - (Page 60) d01gopsh_p4ma 11/9/07 11:18 AM Page 60 State of the Art MEMORY LEAKS DETECTION: A DIFFERENT APPROACH Detecting a Better Tool So let’s make a wish list of requirements for a memory-leaks detection tool (I’m only talking about management of runtime info process all requests made by the same visitor. As you don’t want to keep this information forever, you release all related objects after a timeout of 20 minutes from the visitor’s last • You should be able to stop registering new memory allocations, while still updating the state on each released object. • At time (c), you want to get a report of all memory blocks allocated in time period (a)–(b), which were not released within the (a)–(c) time interval. For the imaginary web server, assume you’ve started the process at 10:00. You can begin all monitoring at 10:10; turn off new allocations tracing at 10:15; and only at 10:40 get the final report of all memory leaks (for objects allocated in the five minutes between 10:10 and 10:15). Such flexibility in activation times and separation of new and delete processing are key points in building a better memory-leaks detection tool. When thinking about additional features it might have, I would add: • Start monitoring only memory allocation made from a specific thread or group of threads. Again, this is a good way to focus on specific areas of processing, ignoring unnecessary There are trade-offs in deciding which tool is most appropriate for your project regarding memory use, and not about techniques to trap allocations/deallocations made by the program): • They should let you begin registering new memory allocations at any arbitrary point of time. You will let the application properly initialize first. • They should stop monitoring memory activities and get a current-leaks report at any time. Returning to the web server example, assume that it holds a session context per user—this is some information needed to request. Figure 1 shows a schematic lifetime of session objects, assuming that you start monitoring at time 1 and end at time 7. At time 7 (when you end memory monitoring), session objects for Ron and Superman are still alive, and they were allocated during the monitoring interval. As a result, those session objects would be listed as memory leaks, even if you know that they aren’t. That is exactly what you tried to prevent. As a solution, you need to rethink the second requirement and replace it with: Need Scalable Infrastructure? Network.com provides Infrastructureas-a-Service for the most demanding compute applications. Get the white paper and get started today. www.network.com Sign up now and get 3 months of On-Demand Computing FREE!* *Up to 200 CPU-hrs. 60 Dr. Dobb’s Journal l www.ddj.com l January 2008 http://www.network.com http://www.network.com http://www.network.com http://www.mcobject.com http://www.mcobject.com/enterprise http://www.ddj.com
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.