Out of memory
|This article does not cite any references or sources. (September 2012)|
Out of memory (OOM) is a state of computer operation (often undesired) where no additional memory can be allocated for use by programs or the operating system. Such a system will be unable to load any additional programs and since many programs may load additional data into memory during execution, these will cease to function correctly. This occurs because all available memory, including disk swap space, has been allocated.
Historically, the out of memory condition was more common than it is now—early computers (including personal computers) and operating systems were limited to small amounts of physical random-access memory (RAM) due to the inability of early processors to address large amounts of memory, as well as cost considerations. Since the advent of virtual memory opened the door for the usage of swap space, the condition is much more rare. This implies that modern software is often worse equipped than older software to deal with such a situation when it does, in fact, occur. Almost all modern programs expect to be able to allocate and de-allocate memory freely at run-time, and tend to fail in uncontrolled ways (crash) when that expectation is not met; older ones often allocated memory only once, checked whether they got enough to do all their work, and then expected no more to be forthcoming, thus either failing immediately with an “out of memory” error message, or working as expected.
Early operating systems, such as MS-DOS, lacked support for multitasking. Programs were allocated physical memory that they could use as they needed. Physical memory is often a scarce resource, and when it was used up by applications—such as applications with Terminate and Stay Resident functionality—no further applications could be started until running applications were closed.
Modern operating systems provide virtual memory, in which processes are given a range of memory, but there is no guarantee that the memory corresponds to physical RAM. Virtual memory can be backed by physical RAM, a file via mmap, or swap space, and the operating system can move virtual memory pages around as it needs. Because virtual memory does not need to be backed by physical memory, exhaustion of it is rare, and usually there are other limits imposed by the operating system on resource consumption.
Due to Moore's law, the amount of physical memory in all computers has grown almost exponentially, although this is offset to some degree by programs and files themselves becoming larger. In most cases, a computer with virtual memory support where the majority of the loaded data resides on the hard disk would probably run so slowly due to excessive paging that it would be considered to have failed, prompting the user to close some programs or reboot. As such, an out of memory message is rarely encountered by applications with modern computers.
The typical OOM case in modern computers happens when the operating system is unable to create any more virtual memory, because all of its potential backing devices have been filled. Operating systems such as Linux will attempt to recover from this type of OOM condition by terminating a low-priority process, a mechanism known as the OOM Killer, which is still vulnerable in some cases to memory leak.
Per-process memory limits 
A system may limit the amount of memory each process may use. Usually a matter of policy, such limitation can also happen when the OS has a larger address space than is available at the process level. Some high-end 32-bit systems come with 8GB or more of system memory, even though any single process can only access 4GB of it in a 32-bit flat memory model.
A process which exceeds its per-process limit and then attempts to allocate further memory - with
malloc(), for example - will return failure. A well-behaved application should handle this situation gracefully; however, many do not. An attempt to allocate memory without checking the result is known as an "unchecked malloc".
See also 
- Linux OOM Killer
- Out of Memory handling
- Article "Minimizing Memory Usage for Creating Application Subprocesses" by Greg Nakhimovsky
- Article "Taming the OOM killer" by Goldwyn Rodrigues
- Article "When Linux Runs Out of Memory" by Mulyadi Santosa
- Paper "Handling “Out Of Memory” Errors" by John Boyland