Developing and managing software is a constant battle between functionality and resource management. This is particularly true when discussing memory allocation and leakage.
As code grows, so does the propensity for memory leaks. These micro snippets steal from the total memory allocation usually as a result of objects that are stored but are inaccessible by the running code. The problem then becomes that either the program consumes too much memory or the process fails because it runs out of memory. In the same fashion, this leakage can impact the computer itself by slowing its performance and taxing the available memory.
Languages with active memory management are particularly vulnerable. The lack of automatic garbage collection (C & C++) makes memory leakage a common dysfunction. Dynamically allocated memory is inaccessible, consuming precious resources. Delphi suffers the same vulnerability despite employing active memory management. Basically no language is safe––even languages with robust garbage-collection, like .Net and Java have, the problem still persists.
Memory Leaks in Managed Code
As most people know, in unmanaged languages, memory leaks persist where memory has been allocated but no references to it exist, so we are unable to free it. Those kinds of leaks are pretty much impossible to create in managed languages unless you call out into unmanaged code or unless there's a bug in the runtime.
However, "weaker" forms of leaks can be prevalent –for instance, when a reference to the memory exists, but the developer thought it didn't. It is assumed the object being referenced would be garbage-collected. Consequently, there is unbounded growth in memory consumption, as you're piling up references to objects that are no longer used, but which can't be garbage-collected because they're still referenced somewhere in your application.
What Is The Potential Impact Of Memory Leakage?
The effects are numerous. A program can run for extended periods, taking memory with it whether as a background task on a server or, in the case of embedded devices, when the application is left running continuously.
Memory can also be consumed in the execution of one-time tasks – this is common in animation and video game production. Should a program request memory but not release it when the program terminates, it can unnecessarily consume resources and become a costly leak source. Programs that run on portable devices commonly reduce processing capability due to their small amount of memory capacity.
AQTime from SmartBear was created to trace memory leaks in applications. AQtime includes three profilers that trace memory and resource leaks:
- The Allocation Profiler: finds memory leaks in applications; it traces the memory use in an application during the application’s run, and it allows you to determine whether the allocated memory blocks or objects remain in memory after the application execution is over.
- The Reference Count Profiler: tracks the creation and deletion of references to interfaced objects, and allows you to pinpoint unreleased references.
- The Resource Profiler: finds resource leaks and resource errors in applications.
The process of leak detection is relatively straightforward:
- First, you would begin by preparing your application for profiling and would then profile it with the Allocation profiler. This would then generate profiling results.
- Next, you would analyze the profiling results and find leaked objects.
- The process would then call for you to view the call stack for all unreleased instances of a leaked class at once. You would then find individual objects that were not destroyed after the application was closed. And finally, obtain the function call stack to track down the creation of the problematic object.
Methodical, Efficient Leak Elimination.
Optimizing performance in software demands close and continued scrutiny of the entire development process.
Detecting memory leaks during excessive function calls, object allocation, unnecessary Windows resources, bottlenecks in SQL, third party calls and loss through unused VCL units can affect both the application and processor performance. Investment in tools and process for memory management and memory leak elimination is invaluable when you are faced with the ramifications of not doing either of those things.
For a more comprehensive view of this information please visit:
Using the Allocation Profiler to Detect Memory Leaks in .NET Applications
Fixing Memory Leaks With AQtime
See also:
