Section 9.1. Design Overview

9.1. Design Overview

Early SunOS versions (SunOS 3 and earlier) were based on the old BSD-style memory system, which was not modularized, and thus it was difficult to move the memory system to different platforms. The virtual memory system was completely redesigned at that time, with the new memory system targeted at SunOS 4.0. The new SunOS 4.0 virtual memory system was built with the following goals in mind:

• Use of a new object-oriented memory management framework

• Support for shared and private memory (copy-on-write)

• Page-based virtual memory management

The VM system that resulted from these design goals provides an open framework that now supports many different memory objects. The most important objects of the memory system are segments, vnodes, and pages. For example, all of the following have been implemented as abstractions of the new memory objects:

• Physical memory, in chunks called pages

• A new virtual file object, known as the vnode

• File systems as hierarchies of vnodes

• Process address spaces as segments of mapped vnodes

• Kernel address space as segments of mapped vnodes

• Mapped hardware devices, such as frame buffers, as segments of hardware-mapped pages

The Solaris virtual memory system we use today is implemented according to the framework of the SunOS 4.0 rewrite. It has been significantly enhanced to provide scalable performance on multiprocessor platforms and has been ported to many platforms. Figure 9.1 shows the layers of the Solaris virtual memory implementation.

Figure 9.1. Solaris Virtual Memory Layers

Physical memory management is done by the hardware MMU and a hardware-specific address translation layer known as the Hardware Address Translation (HAT) layer. Each memory management type has its own specific HAT implementation. Thus, we can separate the common machine-independent memory management layers from the hardware-specific components to minimize the amount of platform-specific code that must be written for each new platform.

The next layer is the address space management layer. Address spaces are mappings of segments, which are created with segment device drivers. Each segment driver manages the mapping of a linear virtual address space into memory pages for different device types (for example, a device such as a graphics frame buffer can be mapped into an address space). The segment layers manage virtual memory as an abstraction of a file. The segment drivers call into the HAT layer to create the translations between the address space they are managing and the underlying physical pages.