In operating system design, virtual memory is an abstraction that represents a process’ address space in the system. From the perspective of the process, they control the entire memory space of the system.
Virtual memory addresses don’t necessarily correspond to the same physical address. This is to allow processes to use the same memory addresses.
Hardware-side
The amount of virtual addresses we can use may differ based on the CPU. In RISC-V (and some other architectures), we have a maximum of 39 bits, allowing for 512 GB of addressable memory that the system can use.
The memory management unit (MMU) functions to transform from a virtual to physical address.
OS-side
-
allows us to move process’ physical memory location without affecting their virtual memory
-
bound registers:
- holds size of the address space
- or holds physical address of the end of the address space
- this is saved and restored during context switches
-
physical memory: array of slots, track which one is free/ in use
-
i.e., free list
-
when process terminates, OS Puts memory back onto free list and cleans up associated data structures
-
when process is waiting, it’s possible to move the process’ address space to another location in memory
-
OS must also provide exception handlers for common exceptions, like out of bound accesses
internal fragmentation: discrete blocks will probably have lots of unused space
OS-side
On POSIX systems, we can use the mmap syscall to manage process’ virtual memory. It maps files to a process’ virtual address space. It returns a pointer (virtual address) that allows us to access the file directly.
mmapjust sets up the page tables and doesn’t read from the file, i.e., it just creates an invalid PTE but keeps track of where on the disk the file chunk is.- Then, when we access it first, it generates a page fault. Only then would the kernel read that entry into memory. This basically ensures only the parts of the file that are used get read into memory.
note distinction betw private, anonymous, shared