| Manual Memory Management |
Article Index for Manual |
Website Links For Manual |
Information AboutManual Memory Management |
| CATEGORIES ABOUT MANUAL MEMORY MANAGEMENT | |
| memory management | |
|
DESCRIPTION All programming languages use manual techniques to determine when to ''allocate'' a new object from the free store. C uses the malloc() function; C++ and Java use the new operator; determination of when an object ought to be created is trivial and unproblematic. The fundamental issue is determination of when an object is no longer needed (ie. is garbage), and arranging for its underlying storage to be returned to the free store so that it may be re-used to satisfy future memory requests. In manual memory allocation, this is also specified manually by the programmer; via functions such as free() in C, or the delete operator in C++. Manual management and correctness Manual memory management is known to enable several major classes of bugs into a program, when used incorrectly.
Languages which exclusively use Garbage Collection are known to avoid the last two classes of defects. Memory leaks can still occur (and bounded leaks frequently occur with generational or conservative garbage collection), but are generally less severe than memory leaks in manual systems. Resource acquisition is initialization Manual memory management has one correctness advantage, which comes into play when objects own scarce system resources (like graphics resources, file handles, or database connections) which must be relinquished when an object is destroyed. Languages with manual management, via the use of Destructor s, can arrange for such actions to occur at the precise time of object destruction; this is known as the Resource Acquisition Is Initialization paradigm (RAII). In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework, use of the Auto_ptr template in the language's standard library to perform memory management is a common paradigm. (It should be noted that auto_ptr is ''not'' suitable for all object usage patterns). Garbage collected languages have difficulty with this paradigm, as it is difficult to define (or determine) when or if a Finalizer method might be called; this is commonly known as the Finalizer Problem . Java and other GC'd languages frequently use manual management for scarce system resources ''besides'' memory (such as Graphics Resource s); any object which manages graphics resources is expected to implement the dispose() method, which releases any such resources and marks the object as inactive. Programmers are expected to invoke dispose() manually as appropriate; in order to prevent "leaking" of scarce graphics resources. Depending on the finalize() method (how Java implements finalizers) to release graphics resources is widely viewed as poor programming practice among Java programmers. Performance Many advocates of manual memory management argue that it affords superior performance when compared to automatic techniques such as Garbage Collection . Manual allocation does not suffer from the long "pause" times often associated with garbage collection (although modern garbage collectors have collection cycles which are often not noticeable), and manual allocation frequently has superior locality of reference. This is especially an issue in Real Time systems, where unbounded collection cycles are generally unacceptable. Manual allocation is also known to be more appropriate for systems where memory is a scarce resource. Memory systems can and do frequently "thrash" as the size of a program's Working Set approaches the size of available memory; unused objects in a garbage-collected system tend to remain in an un-reclaimed state for longer than in manually-managed systems, increasing the effective working set size. On the other hand, manual management has documented performance ''disadvantages'':
CRITICISM The primary motivation of manual memory management, superior performance, becomes increasingly irrelevant on always faster hardware. EXTERNAL LINKS
|
|
|