Editing Memory management (section)

== {{anchor|HEAP}} Manual memory management ==
[[File:External Fragmentation.svg|thumb|450px|An example of external fragmentation]]
{{main|Manual memory management}}
The task of fulfilling an allocation request consists of locating a block of unused memory of sufficient size. Memory requests are satisfied by allocating portions from a large pool{{NoteTag|In some operating systems, e.g., [[OS/360]], the free storage may be subdivided in various ways, e.g., subpools in [[OS/360]], below the line, above the line and above the bar in [[z/OS]].}} of memory called the ''heap''{{NoteTag|Not to be confused with the unrelated [[Heap (data structure)|heap]] data structure.}} or ''free store''. At any given time, some parts of the heap are in use, while some are "free" (unused) and thus available for future allocations.
In the C language, the function which allocates memory from the heap is called {{code|malloc}} and the function which takes previously allocated memory and marks it as "free" (to be used by future allocations) is called {{code|free}}.  {{NoteTag|A simplistic implementation of these two functions can be found in the article "Inside Memory Management".<ref>{{cite web |url=https://developer.ibm.com/tutorials/l-memory/ |title=Inside Memory Management |website=IBM DeveloperWorks |author=Jonathan Bartlett}}</ref> }}

Several issues complicate the implementation, such as [[fragmentation (computer)#External fragmentation|external fragmentation]], which arises when there are many small gaps between allocated memory blocks, which invalidates their use for an allocation request. The allocator's [[metadata (computing)|metadata]] can also inflate the size of (individually) small allocations. This is often managed by [[chunking (computing)|chunking]]. The memory management system must track outstanding allocations to ensure that they do not overlap and that no memory is ever "lost" (i.e. that there are no "[[memory leak]]s").

=== Efficiency ===
The specific dynamic memory allocation algorithm implemented can impact performance significantly. A study conducted in 1994 by [[Digital Equipment Corporation]] illustrates the [[computational overhead|overheads]] involved for a variety of allocators. The lowest average [[instruction path length]] required to allocate a single memory slot was 52 (as measured with an instruction level [[Profiling (computer programming)|profiler]] on a variety of software).<ref name=":0">{{Cite journal | doi = 10.1002/spe.4380240602| title = Memory allocation costs in large C and C++ programs| journal = Software: Practice and Experience| volume = 24| issue = 6| pages = 527–542| date=June 1994 | last1 = Detlefs | first1 = D. | last2 = Dosser | first2 = A. | last3 = Zorn | first3 = B. | url = https://users.cs.northwestern.edu/~robby/uc-courses/15400-2008-spring/spe895.pdf | citeseerx = 10.1.1.30.3073| s2cid = 14214110}}</ref>

=== Implementations ===
Since the precise location of the allocation is not known in advance, the memory is accessed indirectly, usually through a [[Pointer (computer programming)|pointer]] [[reference (computer science)|reference]]. The specific algorithm used to organize the memory area and allocate and deallocate chunks is interlinked with the [[kernel (operating system)|kernel]], and may use any of the following methods:

==== {{Anchor|FIXED-SIZE}}Fixed-size blocks allocation ====
{{main|Memory pool}}
Fixed-size blocks allocation, also called memory pool allocation, uses a [[free list]] of fixed-size blocks of memory (often all of the same size). This works well for simple [[embedded system]]s where no large objects need to be allocated but suffers from [[Fragmentation (computing)|fragmentation]] especially with long memory addresses. However, due to the significantly reduced overhead, this method can substantially improve performance for objects that need frequent allocation and deallocation, and so it is often used in [[video games]].

==== Buddy blocks ====
{{details|Buddy memory allocation}}
In this system, memory is allocated into several pools of memory instead of just one, where each pool represents blocks of memory of a certain [[power of two]] in size, or blocks of some other convenient size progression. All blocks of a particular size are kept in a sorted [[linked list]] or [[Tree data structure|tree]] and all new blocks that are formed during allocation are added to their respective memory pools for later use. If a smaller size is requested than is available, the smallest available size is selected and split. One of the resulting parts is selected, and the process repeats until the request is complete. When a block is allocated, the allocator will start with the smallest sufficiently large block to avoid needlessly breaking blocks. When a block is freed, it is compared to its buddy. If they are both free, they are combined and placed in the correspondingly larger-sized buddy-block list.

==== Slab allocation ====
{{main|Slab allocation}}
This memory allocation mechanism preallocates memory chunks suitable to fit objects of a certain type or size.<ref name="silberschatz">{{cite book |first1 = Abraham |last1 = Silberschatz |author1-link = Abraham Silberschatz |first2 = Peter B. |last2 = Galvin |title = Operating system concepts |publisher = Wiley |year = 2004 |isbn = 0-471-69466-5 }}</ref> These chunks are called caches and the allocator only has to keep track of a list of free cache slots. Constructing an object will use any one of the free cache slots and destructing an object will add a slot back to the free cache slot list. This technique alleviates memory fragmentation and is efficient as there is no need to search for a suitable portion of memory, as any open slot will suffice.

==== Stack allocation ====
{{main|Stack-based memory allocation}}
Many [[Unix-like]] systems as well as [[Microsoft Windows]] implement a function called {{code|alloca}} for dynamically allocating stack memory in a way similar to the heap-based {{code|malloc}}. A compiler typically translates it to inlined instructions manipulating the stack pointer.<ref>{{man|3|alloca|Linux}}</ref> Although there is no need of manually freeing memory allocated this way as it is automatically freed when the function that called {{code|alloca}} returns, there exists a risk of overflow. And since alloca is an ''ad hoc'' expansion seen in many systems but never in POSIX or the C standard, its behavior in case of a stack overflow is undefined.

A safer version of alloca called {{code|_malloca}}, which reports errors, exists on Microsoft Windows. It requires the use of {{code|_freea}}.<ref>{{cite web |title=_malloca |url=https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/malloca?view=vs-2019 |website=Microsoft CRT Documentation | date=26 October 2022 |language=en-us}}</ref> [[gnulib]] provides an equivalent interface, albeit instead of throwing an SEH exception on overflow, it delegates to malloc when an overlarge size is detected.<ref>{{cite web |title=gnulib/malloca.h |url=https://github.com/coreutils/gnulib/blob/master/lib/malloca.h |website=GitHub |access-date=24 November 2019}}</ref> A similar feature can be emulated using manual accounting and size-checking, such as in the uses of {{code|alloca_account}} in glibc.<ref>{{cite web |title=glibc/include/alloca.h |url=https://github.com/bminor/glibc/blob/780684eb04298977bc411ebca1eadeeba4877833/include/alloca.h |publisher=Beren Minor's Mirrors |date=23 November 2019}}</ref>