 | This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages) (Learn how and when to remove this message)
|
Incomputer science,manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, orgarbage. Up until the mid-1990s, the majority ofprogramming languages used in industry supported manual memory management, thoughgarbage collection has existed since 1959, when it was introduced withLisp. Today, however, languages with garbage collection such asJava are increasingly popular and the languagesObjective-C andSwift provide similar functionality throughAutomatic Reference Counting. The main manually managed languages still in widespread use today areC andC++ – seeC dynamic memory allocation.
Many programming languages use manual techniques to determine when toallocate a new object from the free store. C uses themalloc function; C++ and Java use thenew operator; and many other languages (such as Python) allocate all objects from the free store. Determining when an object ought to be created (object creation) is generally trivial and unproblematic, though techniques such asobject pools mean an object may be created before immediate use. The real challenge isobject destruction – determination of when an object is no longer needed (i.e. is garbage), and arranging for its underlying storage to be returned to the free store for re-use. In manual memory allocation, this is also specified manually by the programmer; via functions such asfree() in C, or thedelete operator in C++ – this contrasts with automatic destruction of objects held inautomatic variables, notably (non-static)local variables of functions, which are destroyed at the end of their scope in C and C++.
![[icon]](/mt/?noimg=&dark=on&url=http%3a%2f%2fwww.wikipedia.org%2fwiki%2fFile%3aWiki_letter_w_cropped.svg) | This sectionneeds expansion. You can help byadding to it.(January 2022) |
For example
Manual memory management is known to enable several major classes of bugs into a program when used incorrectly, notably violations ofmemory safety ormemory leaks. These are a significant source ofsecurity bugs.
Languages which exclusively usegarbage 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.
Manual memory management has one correctness advantage, which is that it allows automaticresource management via theresource acquisition is initialization (RAII) paradigm.
This arises when objects own scarcesystem resources (like graphics resources, file handles, or database connections) which must be relinquished when an object is destroyed – when the lifetime of the resource ownership should be tied to the lifetime of the object. Languages with manual management can arrange this by acquiring the resource during object initialization (in the constructor), and releasing during object destruction (in thedestructor), which occurs at a precise time. This is known as Resource Acquisition Is Initialization.
This can also be used with deterministicreference counting. In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework, use of theshared_ptr template in the language's standard library to perform memory management is a common paradigm.shared_ptr isnot suitable for all object usage patterns, however.
This approach is not usable in most garbage collected languages – notably tracing garbage collectors or more advanced reference counting – due to finalization being non-deterministic, and sometimes not occurring at all. That is, it is difficult to define (or determine) when or if afinalizer method might be called; this is commonly known as thefinalizer problem. Java and other languages implementing a garbage collector frequently use manual management for scarce system resourcesbesides memory via thedispose pattern: any object which manages resources is expected to implement thedispose() method, which releases any such resources and marks the object as inactive. Programmers are expected to invokedispose() manually as appropriate to prevent "leaking" of scarce graphics resources. For stack resources (resources acquired and released within a single block of code), this can be automated by various language constructs, such as Python'swith, C#'susing or Java'stry-with-resources.
Many advocates of manual memory management argue that it affords superior performance when compared to automatic techniques such asgarbage collection. Traditionally latency was the biggest advantage, but this is no longer the case. Manual allocation frequently has superiorlocality of reference.[citation needed]
Manual allocation is also known to be more appropriate for systems where memory is a scarce resource, due to faster reclamation. Memory systems can and do frequently "thrash" as the size of a program'sworking set approaches the size of available memory; unused objects in a garbage-collected system remain in an unreclaimed state for longer than in manually managed systems, because they are not immediately reclaimed, increasing the effective working set size.
Manual management has a number of documented performancedisadvantages:
delete and such incur an overhead each time they are made, this overhead can be amortized in garbage collection cycles. This is especially true of multithreaded applications, where delete calls must be synchronized.Latency is a debated point that has changed over time, with early garbage collectors and simple implementations performing very poorly compared to manual memory management, but sophisticated modern garbage collectors often performing as well or better than manual memory management.[citation needed]
Manual allocation does not suffer from the long "pause" times that occur in simple stop-the-world garbage collection, although modern garbage collectors have collection cycles which are often not noticeable.[citation needed]
Manual memory management and garbage collection both suffer from potentially unbounded deallocation times – manual memory management because deallocating a single object may require deallocating its members, and recursively its members' members, etc., while garbage collection may have long collection cycles. This is especially an issue inreal time systems, where unbounded collection cycles are generally unacceptable; real-time garbage collection is possible by pausing the garbage collector, while real-time manual memory management requires avoiding large deallocations, or manually pausing deallocation.
| Hardware | |
|---|---|
| Virtual memory | |
| Segmentation | |
| Allocator | |
| Manual means | |
| Garbage collection | |
| Safety | |
| Issues | |
| Other | |
