Memory management unit

Short description: Hardware that translates virtual addresses to physical addresses

A 68451 MMU, which could be used with the Motorola 68010 VLSI VI475 MMU Apple HMMU from the Macintosh II used with the Motorola 68020

A memory management unit (MMU), sometimes called paged memory management unit (PMMU),[1] is a computer hardware unit that examines all references to memory, and translates the memory addresses being referenced, known as virtual memory addresses, into physical addresses in main memory.

In modern systems, programs generally have addresses that access the theoretical maximum memory of the computer architecture, 32 or 64 bits. The MMU maps the addresses from each program into separate areas in physical memory, which is generally much smaller than the theoretical maximum. This is possible because programs rarely use large amounts of memory at any one time.

Most modern operating systems (OS) work in concert with an MMU to provide virtual memory (VM) support. The MMU tracks memory use in fixed-size blocks known as pages. If a program refers to a location in a page that is not in physical memory, the MMU sends an interrupt to the operating system. The OS selects a lesser-used block in memory, writes it to backing storage such as a hard drive if it has been modified since it was read in, reads the page from backing storage into that block, and sets up the MMU to map the block to the originally requested page so the program can use it. This is known as demand paging. Some simpler real-time operating systems do not support virtual memory and do not need an MMU, but still need a hardware memory protection unit.

MMUs generally provide memory protection to block attempts by a program to access memory it has not previously requested, which prevents a misbehaving program from using up all memory or malicious code from reading data from another program.

In some early microprocessor designs, memory management was performed by a separate integrated circuit such as the VLSI Technology VI475 (1986), the Motorola 68851 (1984) used with the Motorola 68020 CPU in the Macintosh II, or the Z8010[2] and Z8015 (1985)[3][4] used with the Zilog Z8000 family of processors. Later microprocessors (such as the Motorola 68030 and the Zilog Z280) placed the MMU together with the CPU on the same integrated circuit, as did the Intel 80286 and later x86 microprocessors.

Some early systems, especially 8-bit systems, used very simple MMUs to perform bank switching.

## Contents

* 1 Types of address translation
* 1.1 Segmented translation
* 1.2 Paged translation
* 1.3 Segmentation plus paging
* 2 Benefits
* 3 Other memory-related MMU functions
* 4 IOMMUs
* 5 Examples
* 5.1 IBM System/360 Model 67, IBM System/370, and successors
* 5.2 VAX
* 5.3 ARM
* 5.4 DEC Alpha
* 5.5 MIPS
* 5.6 Sun MMU
* 5.7 PowerPC
* 5.8 x86
* 6 Alternatives
* 6.1 Burroughs B5000 series, B6x00/B7x00/B5900/A-series/Unisys MCP systems
* 7 Bank switching
* 8 See also
* 9 References

## Types of address translation

Early systems used base and bounds addressing that further developed into segmentation, or used a fixed set of blocks instead of loading them on demand. The difference between these two approaches is the size of the contiguous block of memory; paged systems break up main memory into a series of equal sized blocks, while segmented systems generally allow for variable sizes.[5]

### Segmented translation

In segmented translation, a memory address contains a segment number and an offset within the segment. Segments are variable-length, and may have permissions, such as read, write, and execute, associated with them.[6] A segment is loaded into a contiguous area of physical memory. Typically, the segment number is used as an index into a segment table; each entry in the segment table holds the address of the area of physical memory, the length of the segment, and other information such as permission flags.

This style has the advantage of simplicity; the memory blocks are continuous and thus only the two values, base and limit, need to be stored for mapping purposes.

The disadvantage of this approach is that it leads to an effect known as external fragmentation. This occurs when memory allocations are released but are non-contiguous. In this case, enough memory may be available to handle a request, but this is spread out and cannot be allocated to a single segment. On systems where programs start and stop over time, this can eventually lead to memory being highly fragmented and no large blocks remaining; in this case, segments would need to be moved in memory, and their segment table entries modified to reflect the new physical address, to make a contiguous space large enough for a segment available.

Some models of the PDP-11 16-bit minicomputer have a segmented memory management unit with a set of page address registers (PARs) and page description registers (PDRs); this maps an 16-bit virtual address to an 18-bit physical address. The PDP-11/70 expands that to produce a 22-bit physical address.[7]

Segmenting was widely used on microcomputer platforms of the 1980s. Among the MMUs that used this concept were the Motorola 68451[5] and the Zilog Z8010, but many other examples exist.

The Intel 8086, Intel 8088, Intel 80186, and Intel 80188 provide crude memory segmentation and no memory protection. (Every byte of every segment is always available to any program.) The 16-bit segment registers allow for 65,536 segments; each segment begins at a fixed offset equal to 16 times the segment number; the segment starting address granularity is 16 bytes. Each segment grants read-write access to 64 KiB (65,536 bytes) of address space (this limit is set by the 16-bit PC and SP registers; the processor does no bounds checking). Offset+address exceeding 0xFFFFF wraps around to 0x00000. Each 64 KiB segment overlaps the next 4,095 segments; each physical address can be denoted by 4,096 segment–offset pairs. This scheme can address only 1 MiB (1024 KiB) of physical memory (and memory-mapped i/o). (Optional expanded memory hardware can add bank-switched memory under software control.) Later x86 processors, starting with the Intel 80286, supported real segmented mapping, with a segment table.

### Paged translation

Schematic of the operation of an MMU[8]: 186 ff.

In paged translation, the address space (the range of addresses used by the processor) is divided into pages, each having a size which is a power of 2, usually a few kilobytes, but they may be much larger. Programs reference memory using the natural address size of the machine, typically 32 or 64 bits in modern systems. The bottom bits of the address (the offset within a page) are left unchanged. The upper address bits are the virtual page numbers.[9]

Most MMUs use an in-memory table of items called a page table, containing one page table entry (PTE) per virtual page, to map virtual page numbers to physical page numbers in main memory. Multi-level page tables are often used to reduce the size of the page table. An associative cache of PTEs is called a translation lookaside buffer (TLB) and is used to avoid the necessity of accessing the main memory every time a virtual address is mapped.[5]

Other MMUs may have a private array of memory,[10] a set of registers,[11] or a one-or-more-level array of static RAM[12] to store a set of mapping information.

The MMU splits the virtual address into a virtual page number and an offset within the page. The virtual page number is used to select a page table entry; if the page table entry is found, and the page is marked as being in memory, the physical page number in the page table entry is combined with the offset to construct the physical address corresponding to the virtual address.[9]

The virtual page number may be directly used as an index into the page table or other mapping information, or it may be further divided, with bits at a given level used as an index into a table of lower-level tables into which bits at the next level down are used as an index, with two or more levels of indexing.

One issue with paged translation is that as the virtual address space expands, the amount of memory needed to hold the mapping increases as well. For instance, in the 68020 the addresses are 32 bits wide, meaning the virtual page number for an 8 kB page size is the upper 19 bits of the address, and a single-level page table would be 512 kB in size.[5] In the 1980s, for an in-memory page table, this might be a significant fraction of the main memory of the machine, and, for an MMU that holds the page map in static RAM, might require a costly amount of static RAM. This problem can be reduced by making the pages larger, say 64 kB instead of 8. Now the page index uses 16 bits and the resulting page table is 64 kB, which is more tractable. Moving to a larger page size leads to the second problem: increased internal fragmentation. A program that generates a series of requests for small blocks will be assigned large blocks and thereby waste large amounts of memory.[5]

If the address space is sparse, so that not all regions of it are allocated, the problem can be reduced by using a multi-level page table or static RAM map, and not allocate all the page table entries that would be needed for an empty region.

The paged translation approach was widely used by microprocessor MMUs in the 1970s and 1980s, including the 68020's 68851 and the on-chip MMU of the 68030, the Zilog Z8000's Z8015, and the NS32000 series's NS16082.

A page table entry or other per-page information may also include information about whether the page has been written to (the dirty bit), when it was last used (the accessed bit, for a least recently used (LRU) page replacement algorithm), what kind of processes (user mode or supervisor mode) may read and write it, and whether it should be cached.[13]

Sometimes, a page table entry or other per-page information prohibits access to a particular virtual page, perhaps because no physical random-access memory (RAM) has been allocated to that virtual page. In this case, the MMU signals a page fault to the CPU. The operating system (OS) then handles the situation, perhaps by trying to find a spare frame of RAM and set up the page map to map it to the requested virtual address. If no RAM is free, it may be necessary to choose an existing page (known as a victim), using some replacement algorithm, and save it to disk (a process called paging). With some MMUs, there can also be a shortage of PTEs, in which case the OS will have to free one for the new mapping.[13][9]

The MMU may also generate illegal access error conditions or invalid page faults upon illegal or non-existing memory accesses, respectively, leading to segmentation fault or bus error conditions when handled by the operating system.

Paged translation mitigates the problem of external fragmentation of memory. After blocks of memory have been allocated and freed, the free memory may become fragmented (discontinuous) so that the largest contiguous block of free memory may be much smaller than the total amount. With virtual memory, a contiguous range of virtual addresses can be mapped to several non-contiguous blocks of physical memory; this non-contiguous allocation is one of the benefits of paging.[13][9]

However, paged translation causes another problem, internal fragmentation. This occurs when a program requests a block of memory that does not cleanly map into a page, for instance, if a program requests a 1 KB buffer to perform file work. In this case, the request results in an entire page being set aside even though only 1 KB of the page will ever be used; if pages are larger than 1 KB, the remainder of the page is wasted. If many small allocations of this sort are made, memory can be used up even though much of it remains empty.[5]

### Segmentation plus paging

Some systems, such as the GE 645 and its successors, used both segmentation and paging. The table of segments, instead of containing per-segment entries giving the physical base address and length of the segment, contains entries giving the physical base address of a page table for the segment, in addition to the length of the segment. Physical memory is divided into fixed-size pages, and the same techniques used for purely page-based demand paging are used for segment-and-page-based demand paging.

The Signetics 68905 MMU, designed for the Motorola 68000, 68010, and 68012 microprocessors, supported segmentation and paging.[14] Both Signetics and Philips produced a version of the 68000 that combined the 68905 on the same physical chip as the processor, the 68070.[5]

## Benefits

An MMU can provide memory protection, so that attempts by code to access or modify data to which it does not have access results in a failure; this catches both software bugs and deliberate attempts to access or modify that data. Typically, an operating system assigns each program its own virtual address space.[9]

An MMU can also be used to expand the size of the physical address when the virtual address is too small. For instance, the PDP-11 originally had a 16-bit address that made it too small as memory sizes increased in the 1970s. This was addressed by expanding the physical memory bus to 18 bits, and using an MMU to add two more bits based on other pins on the processor bus to indicate which program was accessing memory.[15]

## Other memory-related MMU functions

Some MMUs such as the Signetics 68905, also included a controller to manage a processor cache, which stores recently accessed data in a very fast memory and thus reduces the need to talk to the slower main memory.[14] In some implementations, MMUs are also responsible for bus arbitration, controlling access to the memory bus among the many parts of the computer that desire access.

## IOMMUs

Hardware that performs direct memory access completely bypasses the CPU's MMU. Some I/O systems allow DMA hardware to use physical addresses to read or write directly anywhere in physical RAM without any restrictions. Other I/O systems have a separate MMU called an input-output memory management unit (IOMMU) that can be programmed by the OS to translate device addresses from the DMA hardware to specific, limited physical pages chosen by the OS. The IOMMU can be used to block DMA attacks.

## Examples

Most modern systems divide memory into pages that are 4–64 KB in size, often with the capability to use so-called huge pages of 2 MB or 1 GB in size (often both variants are possible). Page translations are cached in a translation lookaside buffer (TLB). Some systems, mainly older RISC designs, trap into the OS when a page translation is not found in the TLB. Most systems use a hardware-based tree walker. Most systems allow the MMU to be disabled, but some disable the MMU when trapping into OS code.

### IBM System/360 Model 67, IBM System/370, and successors

The IBM System/360 Model 67, which was introduced August, 1965, included an MMU called a dynamic address translation (DAT) box.[16][17] It has the unusual feature of storing accessed and dirty bits outside of the page table (along with the four bit protection key for all S/360 processors). They refer to physical memory rather than virtual memory, and are accessed by special-purpose instructions.[17] This reduces overhead for the OS, which would otherwise need to propagate accessed and dirty bits from the page tables to a more physically oriented data structure. This makes OS-level virtualization, later called paravirtualization, easier.

Starting in August, 1972, the IBM System/370 has a similar MMU, although it initially supported only a 24-bit virtual address space rather than the 32-bit virtual address space of the System/360 Model 67. It also stores the accessed and dirty bits outside the page table. In early 1983, the System/370-XA architecture expanded the virtual address space to 31 bits, and in 2000, the 64-bit z/Architecture was introduced, with the address space expanded to 64 bits; those continue to store the accessed and dirty bits outside the page table.

### VAX

VAX pages are 512 bytes,[18]: 199 which is very small. An OS may treat multiple pages as if they were a single larger page. For example, Linux on VAX groups eight pages together. Thus, the system is viewed as having 4 KB pages. The VAX divides memory into four fixed-purpose regions, each 1 GB in size. They are:[18]: 200–201

P0 space
Used for general-purpose per-process memory such as heaps.
P1 space
(Or control space) which is also per-process and is typically used for supervisor, executive, kernel, user stacks and other per-process control structures managed by the operating system.
S0 space
(Or system space) which is global to all processes and stores operating system code and data, whether paged or not, including pagetables.
S1 space
Which is unused and "Reserved to Digital".[18]: 200–201

Page tables are big linear arrays.[18]: 209–215 Normally, this would be very wasteful when addresses are used at both ends of the possible range, but the page tables for P0 and P1 space are stored in the paged S0 space.[18]: 211–212 Thus, there is effectively a two-level tree, allowing applications to have sparse memory layout without wasting a lot of space on unused page table entries. Unlike page table entries in most MMUs, page table entries in the VAX MMU lack an accessed bit.[18]: 203–205 OSes which implement paging must find some way to emulate the accessed bit if they are to operate efficiently. Typically, the OS will periodically unmap pages so that page-not-present faults can be used to let the OS set an accessed bit.

### ARM

ARM architecture-based application processors implement an MMU defined by ARM's virtual memory system architecture (VMSA). The current architecture defines PTEs for describing 4 KB and 64 KB pages, 1 MB sections and 16 MB super-sections; legacy versions also defined a 1 KB tiny page. ARM uses a two-level page table if using 4 KB and 64 KB pages, or just a one-level page table for 1 MB sections and 16 MB sections.

TLB updates are performed automatically by page table walking hardware. PTEs include read/write access permission based on privilege, cacheability information, an NX bit, and a non-secure bit.[19]

### DEC Alpha

DEC Alpha processors divide memory into 8 KB, 16 KB, 32 KB, or 64 KB; the page size is dependent on the processor.[20]: 3–2 [21]: 3–2 pages. After a TLB miss, low-level firmware machine code (here called PALcode) walks a page table.

The OpenVMS AXP PALcode and DEC OSF/1 PALcode walk a three-level tree-structured page table. Addresses are broken down into an unused set of bits (containing the same value as the uppermost bit of the index into the root level of the tree), a set of bits to index the root level of the tree, a set of bits to index the middle level of the tree, a set of bits to index the leaf level of the tree, and remaining bits that pass through to the physical address without modification, indexing a byte within the page. The sizes of the fields are dependent on the page size; all three tree index fields are the same size.[20]: 3-2–3-3 [21]: 3-1–3-2 The OpenVMS AXP PALcode supports full read and write permission bits for user, supervisor, executive, and kernel modes, and also supports fault on read/write/execute bits are also supported.[20]: 3-3–3-6 The DEC OSF/1 PALcode supports full read and write permission bits for user and kernel modes, and also supports fault on read/write/execute bits are also supported.[21]: (II-B) 3-3-3-6

The Windows NT AXP PALcode can either walk a single-level page table in a virtual address space or a two-level page table in physical address space. The upper 32 bits of an address are ignored. For a single-level page table, addresses are broken down into a set of bits to index the page table and remaining bits that pass through to the physical address without modification, indexing a byte within the page. For a two-level page table, addresses are broken down into a set of bits to index the root level of the tree, a set of bits to index the top level of the tree, a set of bits to index the leaf level of the tree, and remaining bits that pass through to the physical address without modification, indexing a byte within the page. The sizes of the fields are dependent on the page size.[22]: 3-2–3-4 The Windows NT AXP PALcode supports a page being accessible only from kernel mode or being accessible from user and kernel mode, and also supports a fault on write bit.[22]: 3-5

### MIPS

The MIPS architecture supports one to 64 entries in the TLB. The number of TLB entries is configurable at CPU configuration before synthesis. TLB entries are dual. Each TLB entry maps a virtual page number (VPN2) to either one of two page frame numbers (PFN0 or PFN1), depending on the least significant bit of the virtual address that is not part of the page mask. This bit and the page mask bits are not stored in the VPN2. Each TLB entry has its own page size, which can be any value from 1 KB to 256 MB in multiples of four. Each PFN in a TLB entry has a caching attribute, a dirty and a valid status bit. A VPN2 has a global status bit and an OS assigned ID which participates in the virtual address TLB entry match, if the global status bit is set to zero. A PFN stores the physical address without the page mask bits.

A TLB refill exception is generated when there are no entries in the TLB that match the mapped virtual address. A TLB invalid exception is generated when there is a match but the entry is marked invalid. A TLB modified exception is generated when a store instruction references a mapped address and the matching entry's dirty status is not set. If a TLB exception occurs when processing a TLB exception, a double fault TLB exception, it is dispatched to its own exception handler.

MIPS32 and MIPS32r2 support 32 bits of virtual address space and up to 36 bits of physical address space. MIPS64 supports up to 64 bits of virtual address space and up to 59 bits of physical address space.

### Sun MMU

The original Sun-1 is a single-board computer built around the Motorola 68000 microprocessor and introduced in 1982. It includes the original Sun 1 memory management unit that provides address translation, memory protection, memory sharing and memory allocation for multiple processes running on the CPU. All access of the CPU to private on-board RAM, external Multibus memory, on-board I/O and the Multibus I/O runs through the MMU, where address translation and protection are done in a uniform fashion. The MMU is implemented in hardware on the CPU board.

The MMU consists of a context register, a segment map and a page map. Virtual addresses from the CPU are translated into intermediate addresses by the segment map, which in turn are translated into physical addresses by the page map. The page size is 2 KB and the segment size is 32 KB which gives 16 pages per segment. Up to 16 contexts can be mapped concurrently. The maximum logical address space for a context is 1024 pages or 2 MB. The maximum physical address that can be mapped simultaneously is also 2 MB.

The context register is important in a multitasking operating system because it allows the CPU to switch between processes without reloading all the translation state information. The 4-bit context register can switch between 16 sections of the segment map under supervisor control, which allows 16 contexts to be mapped concurrently. Each context has its own virtual address space. Sharing of virtual address space and inter-context communications can be provided by writing the same values in to the segment or page maps of different contexts. Additional contexts can be handled by treating the segment map as a context cache and replacing out-of-date contexts on a least-recently used basis.

The context register makes no distinction between user and supervisor states. Interrupts and traps do not switch contexts, which requires that all valid interrupt vectors always be mapped in page 0 of context, as well as the valid supervisor stack.[23]

The Sun-2 workstations are similar; they are built around the Motorola 68010 microprocessor and have a similar memory management unit, with 2 KB pages and 32 KB segments. The context register has a 3-bit system context used in supervisor state and a 3-bit user context used in user state.[24]

The Sun-3 workstations, except for the Sun-3/80, Sun-3/460, Sun-3/470, and Sun-3/480, are built around the Motorola 68020, and have a similar memory management unit. The page size is increased to 8 KB. (The later models are built around the Motorola 68030 and use the 68030's on-chip MMU.)

The Sun-4 workstations are built around various SPARC microprocessors, and have a memory management unit similar to that of the Sun-3 workstations.

### PowerPC

In PowerPC G1, G2, G3, and G4 pages are normally 4 KB. After a TLB miss, the standard PowerPC MMU begins two simultaneous lookups. One lookup attempts to match the address with one of four or eight data block address translation (DBAT) registers, or four or eight instruction block address translation registers (IBAT), as appropriate. The BAT registers can map linear chunks of memory as large as 256 MB, and are normally used by an OS to map large portions of the address space for the OS kernel's own use. If the BAT lookup succeeds, the other lookup is halted and ignored.

The other lookup, not directly supported by all processors in this family, is via a so-called inverted page table, which acts as a hashed off-chip extension of the TLB. First, the top four bits of the address are used to select one of 16 segment registers. Then 24 bits from the segment register replace those four bits, producing a 52-bit address. The use of segment registers allows multiple processes to share the same hash table.

The 52-bit address is hashed, then used as an index into the off-chip table. There, a group of eight-page table entries is scanned for one that matches. If none match due to excessive hash collisions, the processor tries again with a slightly different hash function. If this, too, fails, the CPU traps into OS (with MMU disabled) so that the problem may be resolved. The OS needs to discard an entry from the hash table to make space for a new entry. The OS may generate the new entry from a more normal tree-like page table or from per-mapping data structures which are likely to be slower and more space-efficient. Support for no-execute control is in the segment registers, leading to 256 MB granularity.

A major problem with this design is poor cache locality caused by the hash function. Tree-based designs avoid this by placing the page table entries for adjacent pages in adjacent locations. An operating system running on the PowerPC may minimize the size of the hash table to reduce this problem.

It is also somewhat slow to remove the page table entries of a process. The OS may avoid reusing segment values to delay facing this, or it may elect to suffer the waste of memory associated with per-process hash tables. G1 chips do not search for page table entries, but they do generate the hash, with the expectation that an OS will search the standard hash table via software. The OS can write to the TLB. G2, G3, and early G4 chips use hardware to search the hash table. The latest chips allow the OS to choose either method. On chips that make this optional or do not support it at all, the OS may choose to use a tree-based page table exclusively.

### x86

The x86 architecture has evolved over a very long time while maintaining full software compatibility, even for OS code. Thus, the MMU is extremely complex, with many different possible operating modes.

The 8086/8088 and 80186/80188 have no memory management unit; they support segmentation, but only to support more physical memory than a 16-bit address can support, as the segment number, in a segment register, is multiplied by 16 and added to the segment offset to generate a physical address.

The 80286 added an MMU that supports segmentation, but not paging. When segmentation is enabled by turning on protected mode, the segment number acts as an index into a table of segment descriptors; a segment descriptor contains a base physical address, a segment length, a presence bit to indicate whether the segment is currently in memory, permission bits, and control bits, If the offset in the segment is within the bounds specified by the segment descriptor, that offset is added to the base physical address to generate a physical address.

The 80386, which introduced the 32-bit IA-32 version of x86, and subsequent x86 CPUs, support segmentation and paging. If paging is enabled, the base address in a segment descriptor is an address in a linear paged address space divided into 4 KB pages, so when that is added to the offset in the segment, the resulting address is a linear address in that address space; in IA-32, that address is then masked to be no larger than 32 bits. The result may be looked up via a tree-structured page table, with the bits of the address being split as follows: 10 bits for the branch of the tree, 10 bits for the leaves of the branch, and the 12 lowest bits being directly copied to the result.

Segment registers, used in pre-80386 CPUs to extend the address space, are not used in modern OSes, with one major exception: access to thread-specific data for applications or CPU-specific data for OS kernels, which is done with explicit use of the FS and GS segment registers. All memory access involves a segment register, chosen according to the code being executed. Except when using FS or GS, the OS ensures that the offset will be zero. Some operating systems, such as OpenBSD with its W^X feature, and Linux with the Exec Shield or PaX patches, may also limit the length of the code segment, as specified by the CS register, to disallow execution of code in modifiable regions of the address space.

Minor revisions of the MMU introduced with the Pentium have allowed very large 4 MB pages by skipping the bottom level of the tree (this leaves 10 bits for indexing the first level of page hierarchy with the remaining 10+12 bits being directly copied to the result). Minor revisions of the MMU introduced with the Pentium Pro introduced the physical address extension (PAE) feature, enabling 36-bit physical addresses with 2+9+9 bits for three-level page tables and 12 lowest bits being directly copied to the result. Large pages (2 MB) are also available by skipping the bottom level of the tree (resulting in 2+9 bits for two-level table hierarchy and the remaining 9+12 lowest bits copied directly). In addition, the page attribute table allowed specification of cacheability by looking up a few high bits in a small on-CPU table.

No-execute support was originally only provided on a per-segment basis, making it very awkward to use. More recent x86 chips provide a per-page NX bit (no-execute bit) in the PAE mode. The W^X, Exec Shield, and PaX mechanisms described above emulate per-page non-execute support on machines with x86 processors that lack the NX bit by setting the length of the code segment, with a performance loss and a reduction in the available address space.

Heterogeneous System Architecture (HSA) creates a unified virtual address space for CPUs, GPUs and DSPs, obsoleting the mapping tricks and data copying.

x86-64, the 64-bit version of the x86 architecture, almost entirely removes segmentation in favor of the flat memory model used by almost all operating systems for the 386 or newer processors. In long mode, all segment offsets are ignored, except for the FS and GS segments; linear addresses are 64-bit rather than 32-bit, with the lowest 48 bits of the address being significant. When used with 4 KB pages, the page table tree has four levels instead of three, to handle the larger linear addresses; in some newer x86-64 processors, a fifth page table level can be enabled, to support 57-bit linear addresses. In all levels of the page table, the page table entry includes an NX bit.

48-bit linear addresses are divided as follows: 16 bits unused, nine bits each for four tree levels (for a total of 36 bits), and the 12 lowest bits directly copied to the result. With 2 MB pages, there are only three levels of page table, for a total of 27 bits used in paging and 21 bits of offset. Some newer CPUs also support a 1 GB page with two levels of paging and 30 bits of offset.[25] CPUID can be used to determine if 1 GB pages are supported.

In all three cases, the 16 highest bits are required to be equal to the 48th bit, or in other words, the low 48 bits are sign extended to the higher bits. This is done to allow further expansion of the addressable range, without compromising backwards compatibility.

57-bit linear addresses are divided as follows: 7 bits unused, nine bits each for five tree levels (for a total of 45 bits), and the 12 lowest bits directly copied to the result. The low 57 bits are sign extended.

## Alternatives

### Burroughs B5000 series, B6x00/B7x00/B5900/A-series/Unisys MCP systems

The Burroughs B5000 from 1961 was the first commercial system to support virtual memory (after the Atlas), has no need for an external MMU.[26] The B5000 and its successors up to current Unisys ClearPath MCP (Libra) systems provide the two functions of an MMU — virtual memory addresses and memory protection — with a different architectural approach. Rather than add virtual memory onto a processor not designed for virtual memory, it is integrated in the core design of the processor/system so there is no requirement for an external unit to add functionality of address translation or bounds checking, resulting in unprecedented memory safety and security.

First, in the mapping of virtual memory addresses, instead of needing an MMU, the machines are descriptor-based.[27][28] The uppermost bit of a 48-bit memory word in the Burroughs B5000 series systems indicate whether the word is an user data or a descriptor/control word; descriptors were read-only to user processes and could only be updated by the system (hardware or operating system). Memory words in the B6x00/B7x00/B5900/A-series/Unisys MCP systems have 48 data bits and 3 tag bits (and later systems to current have 4 tag bits) words whose tag is an odd number are read-only to user processes – descriptors have a tag of 5 and code words have a tag of 3.

Each allocated memory block is given a master descriptor with the properties of the block — physical address, size, and whether it is present in main memory or not, in which case on first access the block must be allocated, or if there is an address, it is an address on secondary storage and must be loaded to main memory. All references to code and data are made using a descriptor. When a request is made to access the block for reading or writing, the hardware checks its presence via the presence bit (pbit) in the descriptor.

A pbit[29] of 1 indicates the presence of the block. In this case, the block can be accessed via the physical main-memory address in the descriptor. If the pbit is zero, a pbit interrupt[30] is generated for the MCP (operating system) to make the block present. If the address field is zero, this is the first access to this block, and it is allocated (an init (initial) pbit). If the address field is non-zero, it is a disk address of the block, which has previously been rolled out — the block is fetched from disk, the pbit is set to one and the physical memory address updated to point to the block in memory. This makes descriptors equivalent to a page-table entry in an MMU system, but descriptors are free of a table.

System performance can be monitored through the number of pbit interrupts, which is the count of accesses to descriptors with a zero bit. 'Init' pbits indicate initial allocations or new memory blocks, but a high level of 'other' pbits indicate that the system had to load a block from virtual memory secondary storage. In normal operation this will not occur very much. If there are above average number of other pbits occurring the system might be thrashing, indicating system overload. In production systems, the machine load will be more constant and thus the system configured or tuned to avoid thrashing.

All memory allocation is therefore completely automatic (one of the features of modern systems[31]) and there is no way to allocate blocks other than this mechanism. There are no such calls as malloc or dealloc, since memory blocks are also automatically allocated on pbit interrupt or discarded. The scheme is also lazy, since a block will not be allocated until it is actually referenced. When memory is nearly full, the MCP examines the working set, trying compaction (since the system is segmented, not paged), deallocating read-only segments (such as code-segments which can be restored from their original copy) and, as a last resort, rolling dirty (that is updated) data segments out to disk.

Another way these systems provide a function of a MMU is in protection. Since all accesses are via the descriptor, the hardware can check that all accesses are within bounds and, in the case of a write, that the process has write permission. The MCP system is inherently secure and thus has no need of an MMU to provide this level of memory protection.

Blocks can be shared between processes via copy descriptors in process stacks (a stack is a special system structure representing the execution state of a process). Thus, some processes may have write permission, whereas others do not. Code segments are read-only, thus reentrant and shared between processes. Copy descriptors contain a 20-bit address field giving the index of the master descriptor in the master descriptor array. This also implements a very efficient and secure Interprocess Communication (IPC) mechanism. Blocks can easily be relocated, since only the master descriptor needs to be updated when a block's status changes.

Another aspect is performance - do MMU-based or non-MMU-based systems provide better performance? MCP systems may be implemented on top of standard hardware that does have an MMU (for example, a standard PC). Even if the system implementation uses the MMU in some way, this will not be at all visible at the MCP level.

## Bank switching

A simple technique called bank switching was widely used by early 8-bit microprocessors like the MOS 6502. For instance, the Atari MMU would express additional bits on the address bus to select among several banks of DRAM memory based on which of the chips was currently active, normally the CPU or ANTIC. This was used to expand the available memory on the Atari 130XE to 128 kB.[32] The Commodore 128 used a similar approach.

## See also

* Burroughs large systems descriptors
* Memory controller
* Memory protection unit

## References

1. ↑ Memory Management Unit at the Free On-line Dictionary of Computing
2. ↑ "Z8010 Z8000 MMU Memory Management Unit Product Specification". Zilog. April 1985. http://www.bitsavers.org/components/zilog/z8000/z8000DataSheets/z8010_mmu.pdf.
3. ↑ "1983/84 Data Book". Zilog. pp. 215–234. http://www.bitsavers.org/components/zilog/_dataBooks/1983_84_Components_Data_Book.pdf.
4. ↑ Schmidt, Stephen (April 1983). "Virtual Memory for Microcomputers". Byte 8 (4): 234–235. https://archive.org/details/byte-magazine-1983-04/page/n235/mode/2up?q=z8015.
5. ↑ 5.0 5.1 5.2 5.3 5.4 5.5 5.6 Zehr, Gregg (November 1986). "Memory Management Units For 68000 Architectures". Byte: 127–135. http://marc.retronik.fr/motorola/68K/68000/Memory_Management_Units_for_68000_Architectures_[BYTE_1986_9p].pdf.
6. ↑ Glaser, Edward L.; Couleur, John F.; Oliver, G. A. (1965). "System Design of a Computer for Time Sharing Applications". 1965 Fall Joint Computer Conference. https://multicians.org/fjcc2.html.
7. ↑ "6". PDP-11/70 Processor Handbook. DEC. 1977. https://bitsavers.org/pdf/dec/pdp11/1170/PDP-11_70_Handbook_1977-78.pdf.
8. ↑ Tanenbaum, Andrew S. (2009). Modern operating systems. Upper Saddle River (New Jersey): Prentice-Hall. ISBN 978-0-13-600663-3.
9. ↑ 9.0 9.1 9.2 9.3 9.4 Frank Uyeda (2009). "Lecture 7: Memory Management". CSE 120: Principles of Operating Systems. UC San Diego. http://cseweb.ucsd.edu/classes/su09/cse120/lectures/Lecture7.pdf.
10. ↑ Spectra 70 70/46 Processor Reference Manual. RCA. March 1968. pp. 5–6,12-13. http://bitsavers.trailing-edge.com/pdf/rca/spectra70/model46/70-46-601_70-46_RefMan_Mar68.pdf. Retrieved August 15, 2013.
11. ↑ Reference Manual, SDS 940 Computer. Scientific Data Systems. 1966. pp. 8–10. http://bitsavers.org/pdf/sds/9xx/940/900640A_940_RefMan_Aug66.pdf.
12. ↑ Hardware Engineering Manual for the 2060 CPU Board. Sun Microsystems. 10 May 1987. pp. 121–129. http://bitsavers.org/pdf/sun/sun3/3-100/800-1386-13_2060_CPU_Engineering_Manual.pdf.
13. ↑ 13.0 13.1 13.2 This article is based on material taken from Memory+management+unit at the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.
14. ↑ 14.0 14.1 Microprocessor Data Manual 1986. Signetics. pp. 2-568-2-598. http://www.bitsavers.org/components/signetics/_dataBooks/1986_Signetics_Microprocessor.pdf#page=579.
15. ↑ Bell, Gordon. "A Retrospective on What We Have Learned From the PDP-11". https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper_c1998.htm.
16. ↑ "IBM Archives: System/360 Dates and characteristics". 23 January 2003. http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html.
17. ↑ 17.0 17.1 "IBM System/360 Model 67 Functional Characteristics, Third Edition". February 1972. http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/GA27-2719-2_360-67_funcChar.pdf.
18. ↑ 18.0 18.1 18.2 18.3 18.4 18.5 "Chapter 4 Memory Management". VAX Architecture Reference Manual. Digital Equipment Corporation. 1987. EY-3459E-DP. ISBN 0-932376-86-X. http://bitsavers.org/pdf/dec/vax/archSpec/EY-3459E-DP_VAX_Architecture_Reference_Manual_1987.pdf.
19. ↑ "Cortex-A8 Technical Reference Manual". http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344i/DDI0344I_cortex_a8_r3p1_trm.pdf.
20. ↑ 20.0 20.1 20.2 "Part II-A / OpenVMS AXP Software". Alpha AXP Architecture (Second ed.). Digital Press. 1995. EY-TI32E-DP. ISBN 1-55558-145-5. http://bitsavers.org/pdf/dec/alpha/Sites_AlphaAXPArchitectureReferenceManual_2ed_1995.pdf.
21. ↑ 21.0 21.1 21.2 "Part II-B / DEC OSF/1 Software". Alpha AXP Architecture (Second ed.). Digital Press. 1995. EY-TI32E-DP. ISBN 1-55558-145-5. http://bitsavers.org/pdf/dec/alpha/Sites_AlphaAXPArchitectureReferenceManual_2ed_1995.pdf.
22. ↑ 22.0 22.1 "Part II-C / Windows NT AXP Software". Alpha AXP Architecture (Second ed.). Digital Press. 1995. EY-TI32E-DP. ISBN 1-55558-145-5. http://bitsavers.org/pdf/dec/alpha/Sites_AlphaAXPArchitectureReferenceManual_2ed_1995.pdf.
23. ↑ Sun 68000 Board User's Manual, Sun Microsystems, Inc, February 1983, Revision B
24. ↑ "Sun-2 Architecture Manual". Sun Microsystems. 15 December 1983. pp. 9–12. http://bitsavers.org/pdf/sun/sun2/Sun-2_Architecture_Manual_Dec83.pdf.
25. ↑ "AMD64 Architecture Programmer's Manual Volume 2: System Programming". March 2017. http://support.amd.com/TechDocs/24593.pdf.
26. ↑ Tanenbaum, Andrew S.; Herder, Jorrit N.; Bos, Herbert (May 2006). "Can We Make Operating Systems Reliable and Secure?". Computer 39 (5): 44–51. doi:10.1109/MC.2006.156. https://www.computer.org/csdl/mags/co/2006/05/r5044-abs.html.
27. ↑ "The Descriptor". http://www.bitsavers.org/pdf/burroughs/LargeSystems/B5000_5500_5700/5000-20002-P_The_Descriptor_-_A_Definition_of_the_B_5000_Information_Processing_System_196102.pdf.
28. ↑ "Unisys Descriptor". https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86000387-514/section-000023204.html.
29. ↑ "Pbits". https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86000387-514/section-000023194.html.
30. ↑ "Pbit interrupt". https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86000387-514/section-000023193.html.
31. ↑ Daniel H. H. Ingalls (August 1981). "Design Principles Behind Smalltalk". Byte Magazine. http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html.
32. ↑ MCU, Memory Control Unit, FREDDIE (Technical report). Atari. 1983.

* v
* t
* e

Processor technologies

Models|

* Turing machine
* Universal
* Post–Turing
* Quantum
* Belt machine
* Stack machine
* Finite-state machine
* with datapath
* Hierarchical
* Queue automaton
* Register machines
* Counter
* Pointer
* Random-access
* Random-access stored program

Architecture|

* Microarchitecture
* Von Neumann
* Harvard
* modified
* Dataflow
* Transport-triggered
* Cellular
* Endianness
* Memory access
* NUMA
* HUMA
* Load/store
* Register/memory
* Cache hierarchy
* Memory hierarchy
* Virtual memory
* Secondary storage
* Heterogeneous
* Fabric
* Multiprocessing
* Cognitive
* Neuromorphic

Instruction set
architectures|

| Types|

* CISC
* RISC
* Application-specific
* EDGE
* TRIPS
* VLIW
* EPIC
* MISC
* OISC
* NISC
* ZISC
* comparison
* addressing modes

|

* x86
* ARM
* MIPS
* Power ISA
* SPARC
* Itanium
* Unicore
* MicroBlaze
* RISC-V
* others

Execution|

| Instruction pipelining|

* Pipeline stall
* Operand forwarding
* Classic RISC pipeline

|

Hazards|

* Data dependency
* Structural
* Control
* False sharing

Out-of-order|

* Tomasulo algorithm
* Reservation station
* Re-order buffer
* Register renaming

Speculative|

* Branch prediction
* Memory dependence prediction

Parallelism|

| Level|

* Bit
* Bit-serial
* Word
* Instruction
* Pipelining
* Scalar
* Superscalar
* Task
* Thread
* Process
* Data
* Vector
* Memory
* Distributed

|

Multithreading|

* Temporal
* Simultaneous
* Hyperthreading
* Speculative
* Preemptive
* Cooperative

Flynn's taxonomy|

* SISD
* SIMD
* SWAR
* SIMT
* MISD
* MIMD
* SPMD

Processor
performance|

* Transistor count
* Instructions per cycle (IPC)
* Cycles per instruction (CPI)
* Instructions per second (IPS)
* Floating-point operations per second (FLOPS)
* Transactions per second (TPS)
* Synaptic updates per second (SUPS)
* Performance per watt (PPW)
* Cache performance metrics
* Computer performance by orders of magnitude

Types|

* Central processing unit (CPU)
* Graphics processing unit (GPU)
* GPGPU
* Vector
* Barrel
* Stream
* Coprocessor
* ASIC
* FPGA
* CPLD
* Multi-chip module (MCM)
* System in package (SiP)

| By application|

* Microprocessor
* Microcontroller
* Mobile
* Notebook
* Ultra-low-voltage
* ASIP

|

Systems
on chip|

* System on a chip (SoC)
* Multiprocessor (MPSoC)
* Programmable (PSoC)
* Network on a chip (NoC)

Hardware
accelerators|

* AI accelerator
* Vision processing unit (VPU)
* Physics processing unit (PPU)
* Digital signal processor (DSP)
* Tensor processing unit (TPU)
* Secure cryptoprocessor
* Network processor
* Baseband processor

Word size|

* 1-bit
* 2-bit
* 4-bit
* 8-bit
* 16-bit
* 32-bit
* 48-bit
* 64-bit
* 128-bit
* 256-bit
* 512-bit
* others
* variable

Core count|

* Single-core
* Multi-core
* Manycore
* Heterogeneous architecture

Components|

* Core
* Cache
* CPU cache
* replacement policies
* coherence
* Bus
* Clock rate
* Clock signal
* FIFO

| Functional units|

* Arithmetic logic unit (ALU)
* Address generation unit (AGU)
* Floating-point unit (FPU)
* Memory management unit (MMU)
* Load–store unit
* Translation lookaside buffer (TLB)
* Integrated memory controller (IMC)

|

Logic|

* Combinational
* Sequential
* Glue
* Logic gate
* Quantum
* Array

Registers|

* Processor register
* Status register
* Stack register
* Register file
* Memory buffer
* Program counter

Control unit|

* Instruction unit
* Data buffer
* Write buffer
* Microcode ROM
* Counter

Datapath|

* Multiplexer
* Demultiplexer
* Adder
* Multiplier
* CPU
* Binary decoder
* Address decoder
* Sum addressed decoder
* Barrel shifter

Circuitry|

* Integrated circuit
* 3D
* Mixed-signal
* Power management
* Boolean
* Digital
* Analog
* Quantum
* Switch

Power
management|

* PMU
* APM
* ACPI
* Dynamic frequency scaling
* Dynamic voltage scaling
* Clock gating
* Performance per watt (PPW)
* Race to sleep

Related|

* History of general-purpose CPUs
* Microprocessor chronology
* Processor design
* Digital electronics
* Hardware security module
* Semiconductor device fabrication
* Tick–tock model

* v
* t
* e

Operating systems

General|

* Advocacy
* Comparison
* Forensic engineering
* History
* Hobbyist development
* List
* Timeline
* Usage share

Kernel|

| Architectures|

* Exokernel
* Hybrid
* Microkernel
* Monolithic
* vkernel
* Rump kernel
* Unikernel

|

Components|

* Device driver
* Loadable kernel module
* Microkernel
* User space

Process management|

| Concepts|

* Context switch
* Interrupt
* IPC
* Process
* Process control block
* Real-time
* Thread
* Time-sharing

|

Scheduling
algorithms|

* Computer multitasking
* Fixed-priority preemptive
* Multilevel feedback queue
* Preemptive
* Round-robin
* Shortest job next

Memory management and
resource protection|

* Bus error
* General protection fault
* Memory protection
* Paging
* Protection ring
* Segmentation fault
* Virtual memory

Storage access and
file systems|

* Boot loader
* Defragmentation
* Device file
* File attribute
* Inode
* Journal
* Partition
* Virtual file system
* Virtual tape library

List|

* Acorn
* Arthur
* ARX
* MOS
* RISC iX
* RISC OS
* Amiga Inc.
* AmigaOS
* AmigaOS 1.0-3.9 (Motorola 68000)
* AmigaOS 4 (PowerPC)
* Amiga Unix, a.k.a. Amix
* Amstrad
* AMSDOS
* Contiki
* SymbOS
* Android
* Apple Inc.
* Apple II family
* Apple III
* Apple DOS
* Apple Lisa
* Apple SOS
* Apple Pascal
* ProDOS
* GS/OS
* GNO/ME
* Contiki
* Apple Macintosh
* Classic Mac OS
* A/UX
* Copland
* MkLinux
* Pink
* Rhapsody
* macOS (formerly Mac OS X and OS X)
* macOS Server (formerly Mac OS X Server and OS X Server)
* Apple Network Server
* Apple MessagePad
* Newton OS
* iPhone and iPod Touch
* iOS (formerly iPhone OS)
* iPad
* iPadOS
* Apple Watch
* watchOS
* Apple TV
* tvOS
* Darwin
* iPod
* iPod software (unnamed embedded OS)
* A/ROSE
* Apollo Computer
* Domain/OS
* Atari
* Atari DOS
* Atari TOS
* Atari MultiTOS
* BAE Systems XTS-400
* Be Inc.
* BeOS
* BeIA
* BeOS r5.1d0
* Bell Labs Non-Unix
* BESYS
* Plan 9 from Bell Labs
* Inferno)
* Burroughs Corporation
* Burroughs MCP
* BSD
* Control Data Corporation
* Chippewa Operating System
* Kronos
* NOS (Network Operating System)
* SCOPE)
* Convergent Technologies Operating System
* Cosmos
* Cromemco
* Cromemco DOS
* Cromix
* Data General
* AOS (for 16-bit)
* DG/UX
* RDOS (Real-time DOS)
* Datapoint (CTOS for Z-80)
* DDC-I Inc.
* HeartOS
* Digital Research, Inc.
* CP/M
* CP/M Plus
* CP/M-68K
* CP/M-8000
* CP/M-86
* CP/M-86 Plus
* Concurrent CP/M
* Concurrent CP/M-86
* Concurrent CP/M 8-16
* Concurrent CP/M-68K
* Concurrent DOS
* Concurrent PC DOS
* Concurrent DOS 8-16
* Concurrent DOS 286
* Concurrent DOS XM
* Concurrent DOS 386
* Concurrent DOS 386/MGE
* Concurrent DOS 68K
* DR-DOS
* FlexOS
* FlexOS 186
* FlexOS 286
* FlexOS 68K
* Multiuser DOS
* Datapac Multiuser DOS
* Datapac System Manager, a derivative of Datapac Multiuser DOS
* IMS Multiuser DOS
* MP/M
* MP/M II
* MP/M-86
* MP/M 8-16
* PalmDOS 1.0
* Personal CP/M
* Digital Equipment Corporation
* Batch-11/DOS-11
* OS/8
* RSTS/E
* RSX-11
* RT-11
* TOPS-10
* TOPS-20
* TENEX
* Digital UNIX
* Ultrix
* VMS
* WAITS
* DOS
* ENEA AB OSE
* Fujitsu Towns OS
* General Electric, Honeywell, Bull
* Real-Time Multiprogramming Operating System
* GCOS
* Multics
* Genode
* GNU
* Google
* Android
* Chromium OS
* Chrome OS
* Goobuntu
* Fuchsia)
* Green Hills Software
* INTEGRITY
* INTEGRITY-178B
* µ-velOSity
* Haiku
* Harmony
* Heathkit, Zenith Data Systems
* HDOS
* HT-11
* Hewlett-Packare
* HP-UX
* Multi-Programming Executive
* Honeywell CP-6
* Huawei Harmony OS
* Intel Corporation
* ISIS
* IBM
* Pre-360
* BESYS
* CTSS
* GM OS & GM-NAA I/O
* IBSYS
* SHARE Operating System
* University of Michigan Executive System (UMES)
* OS/360 and successors
* OS/360 and successors
* MVS
* OS/390
* Phoenix/MVS
* z/OS)
* DOS
* DOS/360 and successors on IBM S/360, S/370, and successor mainframes
* BOS/360
* TOS/360
* DOS/VS
* DOS/VSE
* VSE/SP
* VSE/ESA
* z/VSE)
* VM/CMS
* CP/CMS
* CP-40
* CP-67
* VM/370
* VM/XA
* VM/ESA Virtual Machine
* z/VM)
* TPF line
* Airline Control Program ACP
* Transaction Processing Facility)
* Unix-like
* AIX
* UTS (Mainframe UNIX)
* Linux on z Systems
* Others on IBM S/360, S/370, and successor mainframes
* TSS/360
* MUSIC/SP
* ORVYL and WYLBUR
* IBM PC
* PC DOS
* OS/2
* OS/2 Warp
* eComStation)
* Other hardware
* IBM Series 1
* EDX
* RPS
* CPS
* IBM 1130 DM2
* IBM 1800 MPX & TSX
* IBM 8100
* DPCX
* DPPX)
* System 3 DMS
* IBM System 34, 36, 38
* OS/400
* illumos
* IncludeOS
* iOS
* audioOS
* iPadOS
* tvOS
* Linux
* MINIX
* MorphOS
* MUSIC/SP
* Nemesis
* NeXTSTEP
* NOS
* ORVYL
* OS/2
* OS-9
* OSv
* Pick
* QNX
* ReactOS
* RISC OS
* Solaris
* Tandem
* NonStop
* TPF
* TRIPOS
* Unix
* Visi On
* VS/9
* webOS
* Windows
* Xerox 500 series (530 RTB, 560)
* Xinu
* z/OS

Miscellaneous concepts|

* API
* Computer network
* HAL
* Live CD
* Live USB
* OS shell
* CLI
* GUI
* NUI
* TUI
* VUI
* ZUI
* PXE

* v
* t
* e

Memory management

* Memory management as a function of an operating system

Manual memory management|

* Static memory allocation
* C dynamic memory allocation
* new and delete (C++)

Virtual memory|

* Demand paging
* Page table
* Paging
* Virtual memory compression

Hardware|

* Memory management unit
* Translation lookaside buffer

Garbage collection|

* Boehm garbage collector
* Concurrent mark sweep collector
* Finalizer
* Garbage
* Garbage-first collector
* Mark-compact algorithm
* Reference counting
* Tracing garbage collection
* Strong reference
* Weak reference

Memory segmentation|

* Protected mode
* Real mode
* Virtual 8086 mode
* x86 memory segmentation

Memory safety|

* Buffer overflow
* Buffer over-read
* Dangling pointer
* Stack overflow

Issues|

* Fragmentation
* Memory leak
* Unreachable memory

Other|

* Automatic variable
* International Symposium on Memory Management
* Region-based memory management

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Memory management unit. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Memory_management_unit&oldid=3983655"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template