Why implement a traditional vfork() Charles D. Cranor's dissertation on Design and Implementation of UVM (270 pages, gzipped PostScript, pdf) The UVM Virtual Memory System - a paper by Charles D. Cranor and Gurudatta M. Parulkar. UVM is a complete rewrite of the NetBSD virtual memory system, and has proven to be a much better performer than the Mach VM system. UVM also supports advanced features such as page loanout, and is being used in the development of a unified buffer and page cache for NetBSD. Chuck Cranor designed and implemented UVM, Matthew Green handled integration issues and wrote the swap subsystem, Chuck Silvers wrote the anonymous memory object pager (which added support for shared memory), and various other developers have converted the appropriate ports across. Andrew Brown modified UVM to be able to do top down memory management. UVM uses lazy allocation. This means programs can overallocate virtual memory. When UVM detects an out of VM completely condition and a lazy allocated bit of memory is accessed, the offending process will be KILLed and the system will continue. There is also a small buffer of reserve pages only for use by the paging system, which allows the pagedaemon to run comfortably when there is otherwise no free ram. Most of this work was done by Chuck Silvers. UVM is not available in the 1.3.X distributions, but is used on all ports for 1.4 and later. UVM used to be part of another project worked on by Chuck Cranor that started with the letter "U" (for "universal")... however, that project mutated into just UVM... so the "U" doesn't really stand for anything anymore: "UVM" is just a name that is different from (but close to) "vm". In UVM, your total virtual memory is equal to the size of your physical RAM (minus kernel overhead) plus the size of each swap partition. In other words, physical memory doesn't have to be backed by a paging device. This rearranges &man.mmap.2;'ed memory allocations that don't request a specific address such that they start directly below the stack and work from the top down, instead of from the middle upwards. By doing this, the area of space reserved for heap growth and the area of space reserved for &man.mmap.2;'ed allocations are merged, meaning that the heap can grow larger, or a process can mmap more or larger objects. The kernel still uses the traditional ``bottom up'' scheme for its internal memory management. The top down memory allocation scheme is currently offered as kernel option on the i386 port, and the PowerPC ports: bebox, macppc, mvmeppc, ofppc, pmppc, prep, and sandpoint. It is expected that most ports will eventually transition to using top down unconditionally at some point. Refer to the &man.options.4; man page for more information.