Virtual Memory, Address Translation, and I/O Models in Operating Systems

Virtual memory is introduced to overcome the limitations of physical memory. Modern computers consist of CPU, memory, and I/O devices, and memory is designed with a hierarchy (registers, cache, main memory, disk) to balance speed, capacity, and cost.

When multiple large applications run simultaneously, the physical memory becomes a bottleneck. Virtual memory provides each process with a large virtual address space (e.g., 4 GB on a 32‑bit OS) while loading pages into physical memory only when needed.

Address translation converts a virtual address (VA) to a physical address (PA) using a page table. The virtual address is split into a virtual page number (VPN) and an offset (VPO). The Memory Management Unit (MMU) looks up the page‑table entry (PTE) to obtain the physical page frame number (PPN) and combines it with the offset to form PA.

Typical translation steps:

Step 1: CPU generates VA and sends it to the MMU.

Step 2: MMU uses VPN to locate the PTE address (PTEA) and reads the PTE from cache or main memory.

Step 3: Cache or main memory returns the PTE to the MMU.

Step 4: MMU copies the PPN into the high bits of a register and the offset into the low bits, forming PA, which is sent to the memory bus.

Step 5: Cache/main memory returns the requested data to the CPU.

If the PTE’s valid bit is 0, a page‑fault interrupt occurs. The OS selects a free or replaceable physical page, possibly writes back a dirty page, loads the needed page from disk, updates the page table, and resumes the faulting instruction.

To accelerate address translation, modern CPUs use a Translation Lookaside Buffer (TLB), a fast cache of recent PTEs. When the TLB hits, the physical address is obtained without accessing the full page table; on a miss, the normal page‑table walk is performed and the result is cached in the TLB.

Large address spaces cause page‑table size explosion. Multi‑level page tables (e.g., two‑level tables for 32‑bit addresses) split the table into hierarchical structures, allocating lower‑level tables only for the portions of the address space actually used.

Operating systems also separate kernel space and user space to protect privileged instructions and improve stability. System calls provide a controlled interface for user programs to request kernel services such as file I/O.

I/O models:

Blocking vs. non‑blocking I/O: Blocking I/O waits for data to become ready; non‑blocking I/O returns immediately if data is not ready.

Synchronous vs. asynchronous I/O: Synchronous I/O copies data from kernel to user space in the calling thread; asynchronous I/O offloads the copy to kernel threads (e.g., Linux AIO, Windows IOCP).

I/O multiplexing: Mechanisms like select , poll , and epoll allow a single thread to monitor many file descriptors. select and poll use linear scans (O(n)), while epoll uses a red‑black tree for registration and a doubly‑linked list for ready events, achieving O(1) readiness notification.

Reactor patterns: Single‑reactor (single thread handles all events), single‑reactor with worker threads (I/O in one thread, business logic in a pool), and multi‑reactor (main reactor accepts connections, sub‑reactors handle I/O).

Zero‑copy techniques reduce data copies between user and kernel space:

mmap + write maps kernel buffers into user space.

sendfile transfers data directly from a file descriptor to a socket inside the kernel.

DMA‑gather‑copy and splice move data between kernel buffers without CPU copying.

Copy‑on‑write (COW) delays duplication of pages until a write occurs.

In Java, MappedByteBuffer and FileChannel.transferTo/transferFrom provide zero‑copy file I/O.

References are provided at the end of the original article.