Processes need memory, and if there are multiple processes on the same machine, they all their own piece of memory in the same "memory device" (RAM). So, how do you apportion out the memory? You can use a first-fit, best-fit, or even worst-fit system like you allocate space on a disk for files. The problem with these systems is that as processes allocate and deallocate memory, you end up with holes that might be too small to be used for any meaningful allocation, so they just take up space and never get used. (This is a form of memory leak.) Traditional "memory leak" in programming: You allocate space for an object or array or whatever. You finish using it, you never deallocate the pointer to it, and then the pointer itself falls out of scope or is otherwise destroyed. The system believes the memory is allocated, but as there is no longer a pointer to it, there's no way to deallocate it, so the memory is unreachable and thus unusable for the duration of the program. Other than being a good programmer, what techiques are used by the languages themselves to handle memory leaks? Garbage collectors (Java, Python). Periodically, your program will take a break from what it's doing to follow all the pointers to find which allocated memory is unreachable, and then deallocate that memory. You, the programmer, can't control when this happens. In fact, hand deallocation is generally not even allowed under this system. Garbage collection is an automated version of what I learned as the "mark and release" system. Some early languages had a command called "mark" which "marked" all allocated memory by following pointers. And then "release" would deallocated all the marked memory. Memory itself can suffer from memory leaks by having memory holes too small be reasonably allocated so the holes just sit there forever until the machine is rebooted. So, one way to fix this is to use a process called "compaction". From time to time, you move all the allocated memory around so that all the allocated memory is at one end of the RAM, and all of the deallocated memory is at the other end. This is a time consuming process and it involves recalculating pointers for programs already in progress. (You've moved its memory to a different location.) Another way to handle this problem (and this is what most modern systems use) is a "paging" system. With a paging system, a pointer in memory consists of two parts: The first part is the page id, and the second part is the exact memory location within the page. Now, every process is going to have its own page 0, page 1, etc. What the OS does is when it receives a request to access memory, it looks up the page portion of the memory location in a page table. (A simple lookup table), that will give a "frame id". So, if I look up a memory address for page 17, the OS will look up page 17 in the page table and see that maps to frame 472 and gets my stuff from that frame. The frame refers to physical memory, there is only one frame 472, and only I have access to it. The frame size and page size are, of course, the same, and since the page size is constant, this addresses the problem of memory leaks. If I want to allocate a new page, I can just take the first free frame. All pages are the same size, so there is not going to be "holes" resulting allocation and deallocation of various sizes. The page can hold however much the system designates. Let's say the page hold 1K. Then that page (or frame) is allocated to hold 1K. So, let's I, the programmer, allocate space for a variable taking up 5K. To me, this process is invisible. bbbbbb bbbbbbbbbb Page # represent the location of the data within the page I allocate 5K: So, I get assigned 5K beginning at: 000100 0000000000 meaning that my block starts here and ends at 001000 1111111111 From my point of view, this memory is contiguous. From the perspective of my program, the byte after 000110 1111111111 is 000111 0000000000 . But, the operating may assign frames to my page 6 and to my page 7 that are not even closed to each other in the RAM. Maybe my page 6 goes to frame 412 and my page 7 goes to frame 13. The actual 5K data structure is not being stored contiguously on RAM, but from the perspective of my program, it is. If my program deallocates that space, and the OS decides that I don't need those frames anymore, it will free up the frames for use by the system later. One easy to handle frames is that you store a pointer to the first free frame. That free frames stores a pointer to the next free frame so forth. Finding a free frame is easy. Deallocating a frame is easy. You can handle paging with each process getting its own page table. A variant on this system is to have a single page table, called an "inverted page table". The OS has one table, you can look up PID and page number and get the frame number. A related concept to "paging" is "swapping". "Swapping" is when you have more pages out there than frames. There are more processes using memory than you actually have on your machine. And so, from time to time, pages that aren't being used can be written to the "backup store", a storage unit that stores page information. On some systems, swaps can be performed manually from within the program. On some systems, some languages (like COBOL or Pascal) had an "overlay" feature. If a method was designated "overlay", you could swap it out to disk and load up a different method if your program was so large the whole thing couldn't be stored in memory. If a method was swapped to disk, then it couldn't be called without swapping something else to disk and loading that method back up first. YOU HAD TO KNOW WHAT YOU WERE DOING TO GET THIS TO WORK. Not all modern systems use swapping at all. In particular, most hand-held computing devices do not use swapping. The reason for this is that hand-held devices use flash memory. Swapping would happen to frequently that it would wear out your iPhone's hard drive. So, hand-held devices tend to use a different system, where if the device runs out of memory, rather than swapping, it will just terminate unused apps.