Memory management

Memory managementis a form ofresource managementapplied tocomputer memory.The essential requirement of memory management is to provide ways to dynamically allocate portions of memory to programs at their request, and free it for reuse when no longer needed. This is critical to any advanced computer system where more than a singleprocessmight be underway at any time.^[1]

Several methods have been devised that increase the effectiveness of memory management.Virtual memorysystems separate thememory addressesused by a process from actual physical addresses, allowing separation of processes and increasing the size of thevirtual address spacebeyond the available amount ofRAMusingpagingor swapping tosecondary storage.The quality of the virtual memory manager can have an extensive effect on overall systemperformance.The system allows a computer to appear as if it may have more memory available than physically present, thereby allowing multiple processes to share it.

In someoperating systems,e.g.OS/360 and successors,^[2]memory is managed by the operating system.^{[note 1]}In other operating systems, e.g.Unix-likeoperating systems, memory is managed at the application level.

Memory management within an address space is generally categorized as eithermanual memory managementor automatic memory management.

Manual memory management

An example of external fragmentation

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^{[note 2]}of memory called theheap^{[note 3]}orfree 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 calledmallocand the function which takes previously allocated memory and marks it as "free" (to be used by future allocations) is calledfree.^{[note 4]}

Several issues complicate the implementation, such asexternal fragmentation,which arises when there are many small gaps between allocated memory blocks, which invalidates their use for an allocation request. The allocator'smetadatacan also inflate the size of (individually) small allocations. This is often managed bychunking.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 leaks").

Efficiency

The specific dynamic memory allocation algorithm implemented can impact performance significantly. A study conducted in 1994 byDigital Equipment Corporationillustrates theoverheadsinvolved for a variety of allocators. The lowest averageinstruction path lengthrequired to allocate a single memory slot was 52 (as measured with an instruction levelprofileron a variety of software).^[1]

Implementations

Since the precise location of the allocation is not known in advance, the memory is accessed indirectly, usually through apointer reference.The specific algorithm used to organize the memory area and allocate and deallocate chunks is interlinked with thekernel,and may use any of the following methods:

Fixed-size blocks allocation

Fixed-size blocks allocation, also called memory pool allocation, uses afree listof fixed-size blocks of memory (often all of the same size). This works well for simpleembedded systemswhere no large objects need to be allocated but suffers fromfragmentationespecially 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 invideo games.

Buddy blocks

In this system, memory is allocated into several pools of memory instead of just one, where each pool represents blocks of memory of a certainpower of twoin size, or blocks of some other convenient size progression. All blocks of a particular size are kept in a sortedlinked listortreeand 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

This memory allocation mechanism preallocates memory chunks suitable to fit objects of a certain type or size.^[4]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

ManyUnix-likesystems as well asMicrosoft Windowsimplement a function calledallocafor dynamically allocating stack memory in a way similar to the heap-basedmalloc.A compiler typically translates it to inlined instructions manipulating the stack pointer.^[5]Although there is no need of manually freeing memory allocated this way as it is automatically freed when the function that calledallocareturns, there exists a risk of overflow. And since alloca is anad hocexpansion 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_malloca,which reports errors, exists on Microsoft Windows. It requires the use of_freea.^[6]gnulibprovides an equivalent interface, albeit instead of throwing an SEH exception on overflow, it delegates to malloc when an overlarge size is detected.^[7]A similar feature can be emulated using manual accounting and size-checking, such as in the uses ofalloca_accountin glibc.^[8]

Automated memory management

The proper management of memory in an application is a difficult problem, and several different strategies for handling memory management have been devised.

Automatic management of call stack variables

In many programming language implementations, the runtime environment for the program automatically allocates memory in thecall stackfor non-staticlocal variablesof asubroutine,calledautomatic variables,when the subroutine is called, and automatically releases that memory when the subroutine is exited. Special declarations may allow local variables to retain values between invocations of the procedure, or may allow local variables to be accessed by other subroutines. The automatic allocation of local variables makesrecursionpossible, to a depth limited by available memory.

Garbage collection

Garbage collection is a strategy for automatically detecting memory allocated to objects that are no longer usable in a program, and returning that allocated memory to a pool of free memory locations. This method is in contrast to "manual" memory management where a programmer explicitly codes memory requests and memory releases in the program. While automatic garbage collection has the advantages of reducing programmer workload and preventing certain kinds of memory allocation bugs, garbage collection does require memory resources of its own, and can compete with the application program for processor time.

Reference counting

Reference counting is a strategy for detecting that memory is no longer usable by a program by maintaining a counter for how many independent pointers point to the memory. Whenever a new pointer points to a piece of memory, the programmer is supposed to increase the counter. When the pointer changes where it points, or when the pointer is no longer pointing to anything or has itself been freed, the counter should decrease. When the counter drops to zero, the memory should be considered unused and freed. Some reference counting systems require programmer involvement and some are implemented automatically by the compiler. A disadvantage of reference counting is that circular references can develop which cause a memory leak to occur. This can be mitigated by either adding the concept of a "weak reference" (a reference that does not participate in reference counting, but is notified when the thing it is pointing to is no longer valid) or by combining reference counting and garbage collection together.

Memory pools

A memory pool is a technique of automatically deallocating memory based on the state of the application, such as the lifecycle of a request or transaction. The idea is that many applications execute large chunks of code which may generate memory allocations, but that there is a point in execution where all of those chunks are known to be no longer valid. For example, in a web service, after each request the web service no longer needs any of the memory allocated during the execution of the request. Therefore, rather than keeping track of whether or not memory is currently being referenced, the memory is allocated according to the request or lifecycle stage with which it is associated. When that request or stage has passed, all associated memory is deallocated simultaneously.

Systems with virtual memory

Virtual memoryis a method of decoupling the memory organization from the physical hardware. The applications operate on memory viavirtual addresses.Each attempt by the application to access a particular virtual memory address results in the virtual memory address being translated to an actualphysical address.^[9]In this way the addition of virtual memory enables granular control over memory systems and methods of access.

In virtual memory systems the operating system limits how aprocesscan access the memory. This feature, calledmemory protection,can be used to disallow a process to read or write to memory that is not allocated to it, preventing malicious or malfunctioning code in one program from interfering with the operation of another.

Even though the memory allocated for specific processes is normally isolated, processes sometimes need to be able to share information.Shared memoryis one of the fastest techniques forinter-process communication.

Memory is usually classified by access rate intoprimary storageandsecondary storage.Memory management systems, among other operations, also handle the moving of information between these two levels of memory.

Memory management in OS/360 and successors

IBMSystem/360does not support virtual memory.^{[note 5]}Memory isolation ofjobsis optionally accomplished usingprotection keys,assigning storage for each job a different key, 0 for the supervisor or 1–15. Memory management inOS/360is asupervisorfunction. Storage is requested using theGETMAINmacro and freed using theFREEMAINmacro, which result in a call to the supervisor (SVC) to perform the operation.

In OS/360 the details vary depending on how the system isgenerated,e.g., forPCP,MFT,MVT.

In OS/360 MVT, suballocation within a job'sregionor the sharedSystem Queue Area(SQA) is based onsubpools,areas a multiple of 2 KB in size—the size of an area protected by a protection key. Subpools are numbered 0–255.^[10]Within a region subpools are assigned either the job's storage protection or the supervisor's key, key 0. Subpools 0–127 receive the job's key. Initially only subpool zero is created, and all user storage requests are satisfied from subpool 0, unless another is specified in the memory request. Subpools 250–255 are created by memory requests by the supervisor on behalf of the job. Most of these are assigned key 0, although a few get the key of the job. Subpool numbers are also relevant in MFT, although the details are much simpler.^[11]MFT uses fixedpartitionsredefinable by the operator instead of dynamic regions and PCP has only a single partition.

Each subpool is mapped by a list of control blocks identifying allocated and free memory blocks within the subpool. Memory is allocated by finding a free area of sufficient size, or by allocating additional blocks in the subpool, up to the region size of the job. It is possible to free all or part of an allocated memory area.^[12]

The details forOS/VS1are similar^[13]to those for MFT and for MVT; the details forOS/VS2are similar to those for MVT, except that the page size is 4 KiB. For both OS/VS1 and OS/VS2 the sharedSystem Queue Area(SQA) is nonpageable.

InMVSthe address space includes an additional pageable shared area, theCommon Storage Area(CSA), and an additional private area, theSystem Work area(SWA). Also, the storage keys 0-7 are all reserved for use by privileged code.

Notes

^However, the run-time environment for a language processor may subdivide the memory dynamically acquired from the operating system, e.g., to implement a stack.
^In some operating systems, e.g.,OS/360,the free storage may be subdivided in various ways, e.g., subpools inOS/360,below the line, above the line and above the bar inz/OS.
^Not to be confused with the unrelatedheapdata structure.
^A simplistic implementation of these two functions can be found in the article "Inside Memory Management".^[3]
^Except on the Model 67

References

^^a ^bDetlefs, D.; Dosser, A.; Zorn, B. (June 1994)."Memory allocation costs in large C and C++ programs"(PDF).Software: Practice and Experience.24(6): 527–542.CiteSeerX10.1.1.30.3073.doi:10.1002/spe.4380240602.S2CID 14214110.
^"Main Storage Allocation"(PDF).IBM Operating System/360 Concepts and Facilities(PDF).IBM Systems Reference Library (First ed.). IBM Corporation. 1965. p. 74.RetrievedApr 3,2019.
^Jonathan Bartlett."Inside Memory Management".IBM DeveloperWorks.
^Silberschatz, Abraham;Galvin, Peter B. (2004).Operating system concepts.Wiley.ISBN 0-471-69466-5.
^alloca(3)–LinuxProgrammer'sManual– Library Functions
^"_malloca".Microsoft CRT Documentation.
^"gnulib/malloca.h".GitHub.Retrieved24 November2019.
^"glibc/include/alloca.h".Beren Minor's Mirrors. 23 November 2019.
^Tanenbaum, Andrew S. (1992).Modern Operating Systems.Englewood Cliffs, N.J.: Prentice-Hall. p. 90.ISBN 0-13-588187-0.
^OS360Sup,pp.82-85.
^OS360Sup,pp.82.
^IBM Corporation (May 1973).Program Logic: IBM System/360 Operating System MVT Supervisor(PDF).pp. 107–137.RetrievedApr 3,2019.
^OSVS1Dig,p. 2.37-2.39.

Bibliography

Donald Knuth.Fundamental Algorithms,Third Edition. Addison-Wesley, 1997.ISBN 0-201-89683-4.Section 2.5: Dynamic Storage Allocation, pp. 435–456.
Simple Memory Allocation Algorithms Archived5 March 2016 at theWayback Machine(originally published on OSDEV Community)
Wilson, P. R.; Johnstone, M. S.; Neely, M.; Boles, D. (1995). "Dynamic storage allocation: A survey and critical review".Memory Management.Lecture Notes in Computer Science. Vol. 986. pp. 1–116.CiteSeerX10.1.1.47.275.doi:10.1007/3-540-60368-9_19.ISBN 978-3-540-60368-9.
Berger, E. D.; Zorn, B. G.;McKinley, K. S.(June 2001)."Composing High-Performance Memory Allocators"(PDF).Proceedings of the ACM SIGPLAN 2001 conference on Programming language design and implementation.PLDI'01. pp. 114–124.CiteSeerX10.1.1.1.2112.doi:10.1145/378795.378821.ISBN 1-58113-414-2.S2CID 7501376.
Berger, E. D.; Zorn, B. G.;McKinley, K. S.(November 2002)."Reconsidering Custom Memory Allocation"(PDF).Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications.OOPSLA'02. pp. 1–12.CiteSeerX10.1.1.119.5298.doi:10.1145/582419.582421.ISBN 1-58113-471-1.S2CID 481812.
Wilson, Paul R.; Johnstone, Mark S.; Neely, Michael; Boles, David (September 28–29, 1995),Dynamic Storage Allocation: A Survey and Critical Review(PDF),Austin, Texas: Department of Computer SciencesUniversity of Texas,retrieved2017-06-03

OS360Sup: OS Release 21 IBM System/360 Operating System Supervisor Services and Macro Instructions(PDF).IBM Systems Reference Library (Eighth ed.).IBM.September 1974. GC28-6646-7.
OSVS1Dig: OS/VS1 Programmer's Reference Digest Release 6(PDF).Systems (Sixth ed.).IBM.September 15, 1976. GC24-5091-5 with TNLs.

External links

The Memory Management Reference, Beginner's Guide Allocation

[3] However, the run-time environment for a language processor may subdivide the memory dynamically acquired from the operating system, e.g., to implement a stack.

[4] In some operating systems, e.g.,OS/360,the free storage may be subdivided in various ways, e.g., subpools inOS/360,below the line, above the line and above the bar inz/OS.

[5] Not to be confused with the unrelatedheapdata structure.

[7] A simplistic implementation of these two functions can be found in the article "Inside Memory Management".^[3]

[14] Except on the Model 67

[:0-1] Detlefs, D.; Dosser, A.; Zorn, B. (June 1994)."Memory allocation costs in large C and C++ programs"(PDF).Software: Practice and Experience.24(6): 527–542.CiteSeerX10.1.1.30.3073.doi:10.1002/spe.4380240602.S2CID 14214110.

[2] "Main Storage Allocation"(PDF).IBM Operating System/360 Concepts and Facilities(PDF).IBM Systems Reference Library (First ed.). IBM Corporation. 1965. p. 74.RetrievedApr 3,2019.

[6] Jonathan Bartlett."Inside Memory Management".IBM DeveloperWorks.

[silberschatz-8] Silberschatz, Abraham;Galvin, Peter B. (2004).Operating system concepts.Wiley.ISBN 0-471-69466-5.

[9] alloca(3)–LinuxProgrammer'sManual– Library Functions

[10] "_malloca".Microsoft CRT Documentation.

[11] "gnulib/malloca.h".GitHub.Retrieved24 November2019.

[12] "glibc/include/alloca.h".Beren Minor's Mirrors. 23 November 2019.

[13] Tanenbaum, Andrew S. (1992).Modern Operating Systems.Englewood Cliffs, N.J.: Prentice-Hall. p. 90.ISBN 0-13-588187-0.

[FOOTNOTEOS360Sup[httpbitsaversorgpdfibm360osR217_Apr73GC28-6646-7_Supervisor_Services_and_Macro_Instructions_Rel_217_Sep74pdfpage100_82]-85-15] OS360Sup,pp.82-85.

[FOOTNOTEOS360Sup[httpbitsaversorgpdfibm360osR217_Apr73GC28-6646-7_Supervisor_Services_and_Macro_Instructions_Rel_217_Sep74pdfpage100_82]-16] OS360Sup,pp.82.

[SupvrLogic-17] IBM Corporation (May 1973).Program Logic: IBM System/360 Operating System MVT Supervisor(PDF).pp. 107–137.RetrievedApr 3,2019.

[FOOTNOTEOSVS1Dig[httpsbitsaversorgpdfibm370OS_VS1GC24-5091-5_OS_VS1_Release_6_Programmers_Reference_Digest_197609pdfpage114_p._2.37-2.39]-18] OSVS1Dig,p. 2.37-2.39.

[1]

[2]

[note 1]

[note 2]

[note 3]

[note 4]

[4]

[5]

[6]

[7]

[8]

[9]

[note 5]

[10]

[11]

[12]

[13]

[3]