Knowledge

Memory management

Source 📝

610:
where it points, or when the pointer is no longer pointing to any area 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 area it is pointing to is no longer valid) or by combining reference counting and garbage collection together.
807:, areas a multiple of 2 KB in size—the size of an area protected by a protection key. Subpools are numbered 0–255. 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. MFT uses fixed 122: 54: 625:
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.
311: 2114: 2104: 2094: 2084: 2074: 711:
and virtual memory in a process known as overlaying. Burroughs was the first commercial implementation of virtual memory (although developed at Manchester University for the Ferranti Atlas computer) and integrated virtual memory with the system design of the B5000 from the start (in 1961) needing no external memory management unit (MMU).
576:, 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 makes 595:
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.
814:
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
609:
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
594:
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
710:
The memory subsystem manages the physical memory and the virtual memory of the system (both part of the hardware resource). The virtual memory extends physical memory by using extra space on a peripheral device, usually disk. The memory subsystem is responsible for moving code and data between main
461:
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.
714:
The memory subsystem is responsible for mapping logical requests for memory blocks to physical portions of memory (segments) which are found in the list of free segments. Each allocated block is managed by means of a segment descriptor, a special control word containing relevant metadata about the
624:
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
721:
are essential in providing memory safety and security so that operations cannot overflow or underflow the referenced block (commonly known as buffer overflow). Descriptors themselves are protected control words that cannot be manipulated except for specific elements of the MCP OS (enabled by the
475:
This memory allocation mechanism preallocates memory chunks suitable to fit objects of a certain type or size. 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
460:
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
241:. 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 single 529:
provides an equivalent interface, albeit instead of throwing an SEH exception on overflow, it delegates to malloc when an overlarge size is detected. A similar feature can be emulated using manual accounting and size-checking, such as in the uses of
706:
An operating system manages various resources in the computing system. The memory subsystem is the system element for managing memory. The memory subsystem combines the hardware memory resource and the MCP OS software that manages the resource.
429:
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
506:. A compiler typically translates it to inlined instructions manipulating the stack pointer. Although there is no need of manually freeing memory allocated this way as it is automatically freed when the function that called 476:
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.
333:. 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 324:
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 of memory called the
1241: 665:, 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. 715:
segment including address, length, machine type, and the p-bit or ‘presence’ bit which indicates whether the block is in main memory or needs to be loaded from the address given in the descriptor.
1281: 1265: 1471: 356:. 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 " 887:
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.
2054: 542:
The proper management of memory in an application is a difficult problem, and several different strategies for handling memory management have been devised.
1580: 276:. 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. 1715: 1325: 669: 638: 1338: 348:, which arises when there are many small gaps between allocated memory blocks, which invalidates their use for an allocation request. The allocator's 650:. Each attempt by the application to access a particular virtual memory address results in the virtual memory address being translated to an actual 1763: 1345: 1600: 448:
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
2107: 1911: 1735: 1445: 589: 42: 2097: 2117: 1295: 1018: 718: 668:
Even though the memory allocated for specific processes is normally isolated, processes sometimes need to be able to share information.
1032: 1557: 1497: 1391: 1203: 1097: 97: 75: 1180: 381: 368:
The specific dynamic memory allocation algorithm implemented can impact performance significantly. A study conducted in 1994 by
1934: 1708: 1039: 730: 687:. Memory management systems, among other operations, also handle the moving of information between these two levels of memory. 234: 127: 2143: 2059: 619: 393: 337:
and the function which takes previously allocated memory and marks it as "free" (to be used by future allocations) is called
144: 1220: 560:
In many programming language implementations, the runtime environment for the program automatically allocates memory in the
514:
expansion seen in many systems but never in POSIX or the C standard, its behavior in case of a stack overflow is undefined.
392:
Since the precise location of the allocation is not known in advance, the memory is accessed indirectly, usually through a
485: 369: 1919: 1757: 1137: 577: 396: 205: 126: 1896: 1674: 1638: 770: 673: 1954: 646:
is a method of decoupling the memory organization from the physical hardware. The applications operate on memory via
399:. The specific algorithm used to organize the memory area and allocate and deallocate chunks is interlinked with the 2138: 2077: 1964: 1944: 1797: 1701: 1528:
Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
452:
in size, or blocks of some other convenient size progression. All blocks of a particular size are kept in a sorted
31: 1400: 964: 654:. In this way the addition of virtual memory enables granular control over memory systems and methods of access. 256:
used by a process from actual physical addresses, allowing separation of processes and increasing the size of the
2023: 426: 400: 1883: 345: 319: 299: 128: 68: 62: 1688: 2087: 1949: 1924: 1830: 443: 377: 1901: 930:
A simplistic implementation of these two functions can be found in the article "Inside Memory Management".
1853: 1751: 1535: 1475: 1423: 979: 373: 79: 918: 826:
are similar to those for MVT, except that the page size is 4 KiB. For both OS/VS1 and OS/VS2 the shared
789: 785: 781: 754: 288: 257: 38: 1929: 1085: 753:, assigning storage for each job a different key, 0 for the supervisor or 1–15. Memory management in 353: 349: 273: 261: 1540: 1807: 1628: 1516: 1456: 984: 758: 658: 457: 242: 125: 1480: 1428: 2049: 2033: 1959: 1563: 1503: 997: 604: 573: 551: 1468:
Proceedings of the ACM SIGPLAN 2001 conference on Programming language design and implementation
1155: 1520: 1825: 1553: 1493: 1441: 1412: 1387: 1199: 1093: 777: 750: 684: 662: 634: 495: 269: 174: 2002: 1997: 1840: 1545: 1485: 1460: 1433: 989: 811:
redefinable by the operator instead of dynamic regions and PCP has only a single partition.
280: 198: 169: 113: 272:. The quality of the virtual memory manager can have an extensive effect on overall system 1992: 1891: 1678: 1404: 746: 680: 470: 422: 238: 1643: 1582:
OS Release 21 IBM System/360 Operating System Supervisor Services and Macro Instructions
421:
of fixed-size blocks of memory (often all of the same size). This works well for simple
380:
required to allocate a single memory slot was 52 (as measured with an instruction level
352:
can also inflate the size of (individually) small allocations. This is often managed by
248:
Several methods have been devised that increase the effectiveness of memory management.
2007: 1974: 1969: 1815: 1774: 868: 729:
Donald Knuth describes a similar system in Section 2.5 ‘Dynamic Storage Allocation’ of
643: 565: 310: 253: 249: 1657: 2132: 1984: 1787: 1782: 863: 858: 284: 164: 1001: 1507: 1379: 1047:. IBM Systems Reference Library (First ed.). IBM Corporation. 1965. p. 74 449: 179: 1567: 17: 2028: 1067: 453: 431: 412: 357: 191: 159: 1397: 849:(SWA). Also, the storage keys 0–7 are all reserved for use by privileged code. 1792: 742: 569: 561: 555: 291:, memory is managed by the operating system. In other operating systems, e.g. 1437: 298:
Memory management within an address space is generally categorized as either
1939: 1820: 521:, which reports errors, exists on Microsoft Windows. It requires the use of 491: 418: 292: 149: 30:"Memory allocation" redirects here. For memory allocation in the brain, see 1671: 993: 502:
for dynamically allocating stack memory in a way similar to the heap-based
1549: 1489: 1873: 1868: 1858: 1848: 1124: 417:
Fixed-size blocks allocation, also called memory pool allocation, uses a
900:, the free storage may be subdivided in various ways, e.g., subpools in 1863: 1684:
VMem - general malloc/free replacement. Fast thread safe C++ allocator
1623: 1531: 901: 897: 823: 819: 526: 265: 1693: 1422:. Lecture Notes in Computer Science. Vol. 986. pp. 1–116. 1648: 837:
the address space includes an additional pageable shared area, the
1683: 1120: 510:
returns, there exists a risk of overflow. And since alloca is an
905: 723: 1697: 295:
operating systems, memory is managed at the application level.
1633: 1609: 1589: 1411:
Wilson, P. R.; Johnstone, M. S.; Neely, M.; Boles, D. (1995).
1354: 1114: 834: 47: 1297:
Program Logic: IBM System/360 Operating System MVT Supervisor
425:
where no large objects need to be allocated but suffers from
1658:
The Memory Management Reference, Beginner's Guide Allocation
1394:. Section 2.5: Dynamic Storage Allocation, pp. 435–456. 657:
In virtual memory systems the operating system limits how a
120: 822:
are similar to those for MFT and for MVT; the details for
1413:"Dynamic storage allocation: A survey and critical review" 776:
In OS/360 the details vary depending on how the system is
841:(CSA), and two additional private areas, the nonpageable 376:
involved for a variety of allocators. The lowest average
1666: 1736:
Memory management as a function of an operating system
904:, below the line, above the line and above the bar in 344:
Several issues complicate the implementation, such as
1634:
TLSF: a constant time allocator for real-time systems
1198:. Englewood Cliffs, N.J.: Prentice-Hall. p. 90. 965:"Memory allocation costs in large C and C++ programs" 745:
does not support virtual memory. Memory isolation of
2042: 2016: 1983: 1910: 1882: 1839: 1806: 1773: 1744: 1588:. IBM Systems Reference Library (Eighth ed.). 1221:"Stories About the B5000 and People Who Were There" 1013: 1011: 531: 522: 518: 507: 503: 499: 338: 334: 580:possible, to a depth limited by available memory. 769:macro, which result in a call to the supervisor ( 691:Memory Management in Burroughs/Unisys MCP Systems 679:Memory is usually classified by access rate into 1041:IBM Operating System/360 Concepts and Facilities 963:Detlefs, D.; Dosser, A.; Zorn, B. (June 1994). 124: 1602:OS/VS1 Programmer's Reference Digest Release 6 1461:"Composing High-Performance Memory Allocators" 37:This article is about memory management in an 1709: 1629:Sample bit-mapped arena memory allocator in C 199: 8: 2055:International Symposium on Memory Management 1612:. September 15, 1976. GC24-5091-5 with TNLs. 795:In OS/360 MVT, suballocation within a job's 661:can access the memory. This feature, called 546:Automatic management of call stack variables 403:, and may use any of the following methods: 1716: 1702: 1694: 1183:. Beren Minor's Mirrors. 23 November 2019. 737:Memory management in OS/360 and successors 639:Shared memory (interprocess communication) 206: 192: 109: 1539: 1479: 1427: 1407:(originally published on OSDEV Community) 983: 761:function. Storage is requested using the 98:Learn how and when to remove this message 41:. For management of physical memory, see 1672:Memory Management For System Programmers 1521:"Reconsidering Custom Memory Allocation" 309: 61:This article includes a list of general 1386:, Third Edition. Addison-Wesley, 1997. 952: 880: 136: 112: 917:Not to be confused with the unrelated 27:Computer memory management methodology 1357:. March 1973. p. 37. GC28-0661-1 672:is one of the fastest techniques for 590:Garbage collection (computer science) 43:Memory management (operating systems) 7: 1624:"Generic Memory Manager" C++ library 1321: 1277: 1261: 958: 956: 314:An example of external fragmentation 1764:Input–output memory management unit 1639:Slides on Dynamic memory allocation 1398:Simple Memory Allocation Algorithms 1689:Operating System Memory Management 67:it lacks sufficient corresponding 25: 972:Software: Practice and Experience 896:In some operating systems, e.g., 749:is optionally accomplished using 517:A safer version of alloca called 2113: 2112: 2103: 2102: 2093: 2092: 2083: 2082: 2073: 2072: 1347:Introduction to OS/VS2 Release 2 302:or automatic memory management. 245:might be underway at any time. 52: 1935:Concurrent mark sweep collector 1649:The Memory Management Reference 260:beyond the available amount of 2060:Region-based memory management 1592:. September 1974. GC28-6646-7. 620:Region-based memory management 1: 1194:Tanenbaum, Andrew S. (1992). 486:Stack-based memory allocation 370:Digital Equipment Corporation 2108:Memory management algorithms 1920:Automatic Reference Counting 1758:Translation lookaside buffer 1608:. Systems (Sixth ed.). 1515:Berger, E. D.; Zorn, B. G.; 1455:Berger, E. D.; Zorn, B. G.; 1353:. Systems (first ed.). 1294:IBM Corporation (May 1973). 1019:"Unisys MCP Managing Memory" 773:) to perform the operation. 498:implement a function called 407:Fixed-size blocks allocation 2098:Automatic memory management 1897:C dynamic memory allocation 1142:Microsoft CRT Documentation 1088:; Galvin, Peter B. (2004). 674:inter-process communication 629:Systems with virtual memory 538:Automated memory management 384:on a variety of software). 2160: 2118:Memory management software 1965:Tracing garbage collection 1798:Virtual memory compression 1644:Inside A Storage Allocator 1068:"Inside Memory Management" 815:an allocated memory area. 765:macro and freed using the 722:UNSAFE block directive in 632: 617: 602: 587: 549: 483: 468: 441: 410: 317: 227:dynamic storage allocation 36: 32:Neuronal memory allocation 29: 2068: 1731: 1090:Operating system concepts 1033:"Main Storage Allocation" 231:dynamic memory allocation 223:dynamic memory management 1892:Static memory allocation 1884:Manual memory management 1438:10.1007/3-540-60368-9_19 1339:"Virtual Storage Layout" 1196:Modern Operating Systems 1181:"glibc/include/alloca.h" 845:(LSQA) and the pageable 731:‘Fundamental Algorithms’ 320:Manual memory management 306:Manual memory management 300:manual memory management 1950:Garbage-first collector 1925:Boehm garbage collector 1831:x86 memory segmentation 1667:Linux Memory Management 1474:'01. pp. 114–124. 1228:Computer History Museum 843:local system queue area 444:Buddy memory allocation 378:instruction path length 82:more precise citations. 1955:Mark–compact algorithm 1752:Memory management unit 1384:Fundamental Algorithms 994:10.1002/spe.4380240602 939:Except on the Model 67 830:(SQA) is nonpageable. 346:external fragmentation 315: 131: 2144:Computer architecture 1550:10.1145/582419.582421 1490:10.1145/378795.378821 1086:Silberschatz, Abraham 442:Further information: 313: 289:OS/360 and successors 258:virtual address space 252:systems separate the 130: 1902:new and delete (C++) 1534:'02. pp. 1–12. 1403:5 March 2016 at the 285:Burroughs/Unisys MCP 1808:Memory segmentation 1219:Waychoff, Richard. 1127:– Library Functions 1066:Jonathan Bartlett. 839:Common Storage Area 574:automatic variables 494:systems as well as 235:resource management 2050:Automatic variable 2034:Unreachable memory 1960:Reference counting 1930:Cheney's algorithm 1912:Garbage collection 1677:2012-05-10 at the 1303:. pp. 107–137 1156:"gnulib/malloca.h" 1072:IBM DeveloperWorks 803:(SQA) is based on 605:Reference counting 599:Reference counting 584:Garbage collection 552:Automatic variable 316: 145:Process management 132: 2139:Memory management 2126: 2125: 2078:Memory management 1826:Virtual 8086 mode 1725:Memory management 1519:(November 2002). 1447:978-3-540-60368-9 1420:Memory Management 828:System Queue Area 801:System Queue Area 685:secondary storage 663:memory protection 648:virtual addresses 635:Memory protection 496:Microsoft Windows 281:operating systems 270:secondary storage 219:Memory management 216: 215: 155:Memory management 114:Operating systems 108: 107: 100: 18:Memory allocation 16:(Redirected from 2151: 2116: 2115: 2106: 2105: 2096: 2095: 2086: 2085: 2076: 2075: 2003:Dangling pointer 1998:Buffer over-read 1970:Strong reference 1841:Memory allocator 1718: 1711: 1704: 1695: 1613: 1607: 1593: 1587: 1571: 1543: 1525: 1511: 1483: 1465: 1451: 1431: 1417: 1367: 1366: 1364: 1362: 1352: 1343: 1335: 1329: 1319: 1313: 1312: 1310: 1308: 1302: 1291: 1285: 1275: 1269: 1259: 1253: 1252: 1246: 1242:"The Descriptor" 1238: 1232: 1231: 1225: 1216: 1210: 1209: 1191: 1185: 1184: 1177: 1171: 1170: 1168: 1166: 1152: 1146: 1145: 1134: 1128: 1118: 1117: 1110: 1104: 1103: 1082: 1076: 1075: 1063: 1057: 1056: 1054: 1052: 1046: 1037: 1029: 1023: 1022: 1015: 1006: 1005: 987: 969: 960: 940: 937: 931: 928: 922: 915: 909: 894: 888: 885: 847:System Work area 818:The details for 768: 764: 703: 702: 698: 652:physical address 533: 524: 520: 509: 505: 501: 480:Stack allocation 423:embedded systems 372:illustrates the 340: 336: 254:memory addresses 208: 201: 194: 123: 110: 103: 96: 92: 89: 83: 78:this article by 69:inline citations 56: 55: 48: 21: 2159: 2158: 2154: 2153: 2152: 2150: 2149: 2148: 2129: 2128: 2127: 2122: 2064: 2038: 2012: 1993:Buffer overflow 1979: 1906: 1878: 1835: 1802: 1769: 1740: 1727: 1722: 1679:Wayback Machine 1620: 1605: 1599: 1585: 1579: 1560: 1541:10.1.1.119.5298 1523: 1517:McKinley, K. S. 1514: 1500: 1463: 1457:McKinley, K. S. 1454: 1448: 1415: 1410: 1405:Wayback Machine 1376: 1371: 1370: 1360: 1358: 1350: 1341: 1337: 1336: 1332: 1320: 1316: 1306: 1304: 1300: 1293: 1292: 1288: 1276: 1272: 1260: 1256: 1244: 1240: 1239: 1235: 1223: 1218: 1217: 1213: 1206: 1193: 1192: 1188: 1179: 1178: 1174: 1164: 1162: 1154: 1153: 1149: 1136: 1135: 1131: 1113: 1112: 1111: 1107: 1100: 1084: 1083: 1079: 1065: 1064: 1060: 1050: 1048: 1044: 1035: 1031: 1030: 1026: 1017: 1016: 1009: 967: 962: 961: 954: 949: 944: 943: 938: 934: 929: 925: 921:data structure. 916: 912: 895: 891: 886: 882: 877: 855: 766: 762: 751:protection keys 739: 704: 700: 696: 694: 693: 681:primary storage 641: 633:Main articles: 631: 622: 616: 607: 601: 592: 586: 566:local variables 564:for non-static 558: 548: 540: 488: 482: 473: 471:Slab allocation 467: 465:Slab allocation 446: 440: 415: 409: 390: 388:Implementations 366: 322: 308: 268:or swapping to 239:computer memory 233:) is a form of 212: 137:Common features 129: 121: 104: 93: 87: 84: 74:Please help to 73: 57: 53: 46: 35: 28: 23: 22: 15: 12: 11: 5: 2157: 2155: 2147: 2146: 2141: 2131: 2130: 2124: 2123: 2121: 2120: 2110: 2100: 2090: 2088:Virtual memory 2080: 2069: 2066: 2065: 2063: 2062: 2057: 2052: 2046: 2044: 2040: 2039: 2037: 2036: 2031: 2026: 2020: 2018: 2014: 2013: 2011: 2010: 2008:Stack overflow 2005: 2000: 1995: 1989: 1987: 1981: 1980: 1978: 1977: 1975:Weak reference 1972: 1967: 1962: 1957: 1952: 1947: 1942: 1937: 1932: 1927: 1922: 1916: 1914: 1908: 1907: 1905: 1904: 1899: 1894: 1888: 1886: 1880: 1879: 1877: 1876: 1871: 1866: 1861: 1856: 1851: 1845: 1843: 1837: 1836: 1834: 1833: 1828: 1823: 1818: 1816:Protected mode 1812: 1810: 1804: 1803: 1801: 1800: 1795: 1790: 1785: 1779: 1777: 1775:Virtual memory 1771: 1770: 1768: 1767: 1761: 1755: 1748: 1746: 1742: 1741: 1739: 1738: 1732: 1729: 1728: 1723: 1721: 1720: 1713: 1706: 1698: 1692: 1691: 1686: 1681: 1669: 1663: 1662: 1661: 1660: 1652: 1651: 1646: 1641: 1636: 1631: 1626: 1619: 1618:External links 1616: 1615: 1614: 1597: 1594: 1577: 1573: 1572: 1558: 1512: 1498: 1452: 1446: 1408: 1395: 1375: 1372: 1369: 1368: 1330: 1314: 1286: 1270: 1254: 1233: 1211: 1204: 1186: 1172: 1147: 1129: 1105: 1098: 1077: 1058: 1024: 1007: 985:10.1.1.30.3073 978:(6): 527–542. 951: 950: 948: 945: 942: 941: 932: 923: 910: 889: 879: 878: 876: 873: 872: 871: 869:Heap pollution 866: 861: 854: 851: 799:or the shared 738: 735: 692: 689: 644:Virtual memory 630: 627: 618:Main article: 615: 612: 603:Main article: 600: 597: 588:Main article: 585: 582: 547: 544: 539: 536: 532:alloca_account 484:Main article: 481: 478: 469:Main article: 466: 463: 439: 436: 411:Main article: 408: 405: 389: 386: 365: 362: 318:Main article: 307: 304: 250:Virtual memory 214: 213: 211: 210: 203: 196: 188: 185: 184: 183: 182: 177: 172: 167: 165:Device drivers 162: 157: 152: 147: 139: 138: 134: 133: 117: 116: 106: 105: 60: 58: 51: 26: 24: 14: 13: 10: 9: 6: 4: 3: 2: 2156: 2145: 2142: 2140: 2137: 2136: 2134: 2119: 2111: 2109: 2101: 2099: 2091: 2089: 2081: 2079: 2071: 2070: 2067: 2061: 2058: 2056: 2053: 2051: 2048: 2047: 2045: 2041: 2035: 2032: 2030: 2027: 2025: 2024:Fragmentation 2022: 2021: 2019: 2015: 2009: 2006: 2004: 2001: 1999: 1996: 1994: 1991: 1990: 1988: 1986: 1985:Memory safety 1982: 1976: 1973: 1971: 1968: 1966: 1963: 1961: 1958: 1956: 1953: 1951: 1948: 1946: 1943: 1941: 1938: 1936: 1933: 1931: 1928: 1926: 1923: 1921: 1918: 1917: 1915: 1913: 1909: 1903: 1900: 1898: 1895: 1893: 1890: 1889: 1887: 1885: 1881: 1875: 1872: 1870: 1867: 1865: 1862: 1860: 1857: 1855: 1852: 1850: 1847: 1846: 1844: 1842: 1838: 1832: 1829: 1827: 1824: 1822: 1819: 1817: 1814: 1813: 1811: 1809: 1805: 1799: 1796: 1794: 1791: 1789: 1788:Memory paging 1786: 1784: 1783:Demand paging 1781: 1780: 1778: 1776: 1772: 1765: 1762: 1759: 1756: 1753: 1750: 1749: 1747: 1743: 1737: 1734: 1733: 1730: 1726: 1719: 1714: 1712: 1707: 1705: 1700: 1699: 1696: 1690: 1687: 1685: 1682: 1680: 1676: 1673: 1670: 1668: 1665: 1664: 1659: 1656: 1655: 1654: 1653: 1650: 1647: 1645: 1642: 1640: 1637: 1635: 1632: 1630: 1627: 1625: 1622: 1621: 1617: 1611: 1604: 1603: 1598: 1595: 1591: 1584: 1583: 1578: 1575: 1574: 1569: 1565: 1561: 1559:1-58113-471-1 1555: 1551: 1547: 1542: 1537: 1533: 1529: 1522: 1518: 1513: 1509: 1505: 1501: 1499:1-58113-414-2 1495: 1491: 1487: 1482: 1481:10.1.1.1.2112 1477: 1473: 1469: 1462: 1459:(June 2001). 1458: 1453: 1449: 1443: 1439: 1435: 1430: 1429:10.1.1.47.275 1425: 1421: 1414: 1409: 1406: 1402: 1399: 1396: 1393: 1392:0-201-89683-4 1389: 1385: 1381: 1378: 1377: 1373: 1356: 1349: 1348: 1340: 1334: 1331: 1327: 1323: 1318: 1315: 1299: 1298: 1290: 1287: 1283: 1279: 1274: 1271: 1267: 1263: 1258: 1255: 1250: 1243: 1237: 1234: 1229: 1222: 1215: 1212: 1207: 1205:0-13-588187-0 1201: 1197: 1190: 1187: 1182: 1176: 1173: 1161: 1157: 1151: 1148: 1143: 1139: 1133: 1130: 1126: 1123:Programmer's 1122: 1119: –  1116: 1109: 1106: 1101: 1099:0-471-69466-5 1095: 1091: 1087: 1081: 1078: 1073: 1069: 1062: 1059: 1043: 1042: 1034: 1028: 1025: 1020: 1014: 1012: 1008: 1003: 999: 995: 991: 986: 981: 977: 973: 966: 959: 957: 953: 946: 936: 933: 927: 924: 920: 914: 911: 907: 903: 899: 893: 890: 884: 881: 874: 870: 867: 865: 864:Out of memory 862: 860: 859:Dynamic array 857: 856: 852: 850: 848: 844: 840: 836: 831: 829: 825: 821: 816: 812: 810: 806: 802: 798: 793: 791: 787: 783: 779: 774: 772: 760: 756: 752: 748: 744: 736: 734: 732: 727: 725: 720: 716: 712: 708: 699: 690: 688: 686: 682: 677: 675: 671: 670:Shared memory 666: 664: 660: 655: 653: 649: 645: 640: 636: 628: 626: 621: 613: 611: 606: 598: 596: 591: 583: 581: 579: 575: 571: 567: 563: 557: 553: 545: 543: 537: 535: 528: 515: 513: 497: 493: 487: 479: 477: 472: 464: 462: 459: 455: 451: 445: 437: 435: 433: 428: 427:fragmentation 424: 420: 414: 406: 404: 402: 398: 395: 387: 385: 383: 379: 375: 371: 363: 361: 359: 355: 351: 347: 342: 332: 328: 321: 312: 305: 303: 301: 296: 294: 290: 286: 282: 277: 275: 271: 267: 263: 259: 255: 251: 246: 244: 240: 236: 232: 228: 224: 220: 209: 204: 202: 197: 195: 190: 189: 187: 186: 181: 178: 176: 173: 171: 168: 166: 163: 161: 158: 156: 153: 151: 148: 146: 143: 142: 141: 140: 135: 119: 118: 115: 111: 102: 99: 91: 81: 77: 71: 70: 64: 59: 50: 49: 44: 40: 39:address space 33: 19: 1724: 1601: 1581: 1527: 1467: 1419: 1383: 1380:Donald Knuth 1374:Bibliography 1359:. Retrieved 1346: 1333: 1326:p. 2.37-2.39 1317: 1305:. Retrieved 1296: 1289: 1273: 1257: 1248: 1236: 1227: 1214: 1195: 1189: 1175: 1163:. Retrieved 1159: 1150: 1141: 1132: 1108: 1089: 1080: 1071: 1061: 1049:. Retrieved 1040: 1027: 975: 971: 935: 926: 913: 892: 883: 846: 842: 838: 832: 827: 817: 813: 808: 804: 800: 796: 794: 780:, e.g., for 775: 740: 728: 717: 713: 709: 705: 678: 667: 656: 651: 647: 642: 623: 614:Memory pools 608: 593: 559: 541: 516: 511: 489: 474: 450:power of two 447: 438:Buddy blocks 416: 391: 367: 358:memory leaks 343: 330: 326: 323: 297: 278: 247: 230: 226: 222: 218: 217: 180:Input/output 154: 94: 85: 66: 2029:Memory leak 1280:, pp.  1264:, pp.  1165:24 November 719:Descriptors 454:linked list 432:video games 413:Memory pool 274:performance 237:applied to 160:File system 80:introducing 2133:Categories 1793:Page table 1138:"_malloca" 947:References 809:partitions 759:supervisor 743:System/360 570:subroutine 562:call stack 556:Call stack 550:See also: 534:in glibc. 364:Efficiency 331:free store 170:Networking 150:Interrupts 88:April 2014 63:references 1940:Finalizer 1821:Real mode 1536:CiteSeerX 1476:CiteSeerX 1424:CiteSeerX 1249:Bitsavers 1115:alloca(3) 1092:. Wiley. 980:CiteSeerX 778:generated 578:recursion 572:, called 492:Unix-like 419:free list 397:reference 374:overheads 293:Unix-like 1874:ptmalloc 1869:mimalloc 1859:jemalloc 1849:dlmalloc 1745:Hardware 1675:Archived 1596:OSVS1Dig 1576:OS360Sup 1401:Archived 1361:July 15, 1322:OSVS1Dig 1278:OS360Sup 1262:OS360Sup 1002:14214110 853:See also 805:subpools 767:FREEMAIN 519:_malloca 382:profiler 354:chunking 350:metadata 279:In some 175:Security 1945:Garbage 1864:libumem 1766:(IOMMU) 1508:7501376 763:GETMAIN 659:process 394:pointer 283:, e.g. 243:process 76:improve 2017:Issues 1568:481812 1566:  1556:  1538:  1532:OOPSLA 1506:  1496:  1478:  1444:  1426:  1390:  1307:Apr 3, 1202:  1160:GitHub 1125:Manual 1096:  1051:Apr 3, 1000:  982:  902:OS/360 898:OS/360 824:OS/VS2 820:OS/VS1 797:region 755:OS/360 695:": --> 527:gnulib 523:_freea 512:ad hoc 508:alloca 504:malloc 500:alloca 401:kernel 335:malloc 287:, and 266:paging 264:using 221:(also 65:, but 2043:Other 1854:Hoard 1760:(TLB) 1754:(MMU) 1606:(PDF) 1586:(PDF) 1564:S2CID 1524:(PDF) 1504:S2CID 1464:(PDF) 1416:(PDF) 1351:(PDF) 1342:(PDF) 1301:(PDF) 1245:(PDF) 1224:(PDF) 1121:Linux 1045:(PDF) 1036:(PDF) 998:S2CID 968:(PDF) 875:Notes 757:is a 568:of a 490:Many 229:, or 1554:ISBN 1494:ISBN 1472:PLDI 1442:ISBN 1388:ISBN 1363:2024 1309:2019 1268:-85. 1200:ISBN 1167:2019 1094:ISBN 1053:2019 919:heap 906:z/OS 747:jobs 741:IBM 724:NEWP 697:edit 683:and 637:and 554:and 458:tree 360:"). 341:. 339:free 327:heap 1610:IBM 1590:IBM 1546:doi 1486:doi 1434:doi 1355:IBM 990:doi 835:MVS 833:In 790:MVT 786:MFT 782:PCP 771:SVC 726:). 456:or 329:or 262:RAM 2135:: 1562:. 1552:. 1544:. 1530:. 1526:. 1502:. 1492:. 1484:. 1470:. 1466:. 1440:. 1432:. 1418:. 1382:. 1344:. 1324:, 1282:82 1266:82 1247:. 1226:. 1158:. 1140:. 1070:. 1038:. 1010:^ 996:. 988:. 976:24 974:. 970:. 955:^ 792:. 788:, 784:, 733:. 676:. 525:. 434:. 225:, 1717:e 1710:t 1703:v 1570:. 1548:: 1510:. 1488:: 1450:. 1436:: 1365:. 1328:. 1311:. 1284:. 1251:. 1230:. 1208:. 1169:. 1144:. 1102:. 1074:. 1055:. 1021:. 1004:. 992:: 908:. 701:] 207:e 200:t 193:v 101:) 95:( 90:) 86:( 72:. 45:. 34:. 20:)

Index

Memory allocation
Neuronal memory allocation
address space
Memory management (operating systems)
references
inline citations
improve
introducing
Learn how and when to remove this message
Operating systems
Process management
Interrupts
Memory management
File system
Device drivers
Networking
Security
Input/output
v
t
e
resource management
computer memory
process
Virtual memory
memory addresses
virtual address space
RAM
paging
secondary storage

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.