In computing, a virtual address space or address space is the set of ranges of virtual addresses that an operating system makes available to a process. The range of virtual addresses usually starts at a low address and can extend to the highest address allowed by the computer's instruction set architecture and supported by the operating system's pointer sizeimplementation, which can be 4 bytes for 32-bit or 8 bytes for 64-bit OS versions. This provides several benefits, one of which is security through process isolation assuming each process is given a separate address space.
Example
When a new application on a 32-bit OS is executed, the process has a VAS: each one of the memory addresses in that space can have a single byte as a value. Initially, none of them have values. Using or setting values in such a VAS would cause a memory exception. 0 4 GiB VAS |----------------------------------------------| Then the application's executable file is mapped into the VAS. Addresses in the process VAS are mapped to bytes in the exe file. The OS manages the mapping: 0 4 GiB VAS |---vvvvvvv------------------------------------| mapping |-----| file bytes app.exe The v's are values from bytes in the mapped file. Then, required DLL files are mapped : 0 4 GiB VAS |---vvvvvvv----vvvvvv---vvvv-------------------| mapping ||||||| |||||| |||| file bytes app.exe kernel user The process then starts executing bytes in the exe file. However, the only way the process can use or set '-' values in its VAS is to ask the OS to map them to bytes from a file. A common way to use VAS memory in this way is to map it to the page file. The page file is a single file, but multiple distinct sets of contiguous bytes can be mapped into a VAS: 0 4 GiB VAS |---vvvvvvv----vvvvvv---vvvv----vv---v----vvv--| mapping ||||||| |||||| |||| || | ||| file bytes app.exe kernel user system_page_file And different parts of the page file can map into the VAS of different processes: 0 4 GiB VAS 1 |---vvvv-------vvvvvv---vvvv----vv---v----vvv--| mapping |||| |||||| |||| || | ||| file bytes app1 app2 kernel user system_page_file mapping |||| |||||| |||| || | VAS 2 |--------vvvv--vvvvvv---vvvv-------vv---v------| On Microsoft Windows 32-bit, by default, only are made available to processes for their own use. The other are used by the operating system. On later 32-bit editions of Microsoft Windows it is possible to extend the user-mode virtual address space to while only is left for kernel-mode virtual address space by marking the programs as IMAGE_FILE_LARGE_ADDRESS_AWARE and enabling the /3GB switch in the boot.ini file. On Microsoft Windows 64-bit, in a process running an executable that was linked with /LARGEADDRESSAWARE:NO, the operating system artificially limits the user mode portion of the process's virtual address space to 2 GiB. This applies to both 32- and 64-bit executables. Processes running executables that were linked with the /LARGEADDRESSAWARE:YES option, which is the default for 64-bit Visual Studio 2010 and later, have access to more than of virtual address space: Up to for 32-bit executables, up to for 64-bit executables in Windows through Windows 8, and up to for 64-bit executables in Windows 8.1 and later. Allocating memory viaC'smalloc establishes the page file as the backing store for any new virtual address space. However, a process can also explicitly map file bytes.
For x86 CPUs, Linux 32-bit allows splitting the user and kernel address ranges in different ways: 3G/1G user/kernel, 1G/3G user/kernel or 2G/2G user/kernel.
