Section 1.3. The Mach Factor

1.3. The Mach Factor

Along with NeXT's operating system came its kernel, which became the kernel foundation of Apple's future systems. Let us now briefly discuss the origins and evolution of Macha key component of the NEXTSTEP kernel and, in turn, of the Mac OS X kernel.

1.3.1. Rochester's Intelligent Gateway

A group of researchers at the University of Rochester, New York, began development of an "intelligent" gateway system named RIG (Rochester's Intelligent Gateway) in 1975. Jerry Feldman, who coined the name RIG, largely did the system's initial design. RIG was meant to provide uniform accesssay, via terminalsto a variety of local and remote computing facilities. Local facilities could be locally connected disks, magnetic tapes, printers, plotters, batch-processing or timesharing computers, and so on. Remote facilities could be available through a network such as the ARPANET. RIG's operating system, called Aleph, ran on a Data General Eclipse minicomputer.

The Aleph kernel was structured around an interprocess communication (IPC) facility. RIG processes could send messages to each other, with a port specifying the destination. A port was an in-kernel message queue that was globally identified by a dotted pair of integers: a process number and a port number. A process could have several ports defined within itself, each of which could be used to wait for a message to arrive on. A process X could shadow or interpose another process Y. In the case of shadowing, X received a copy of every message sent to Y. While interposing, X intercepted all messages sent to or originating from Y. This IPC facility based on messages and ports was a basic building block of the operating system.

RIG was killed a few years later due to several fundamental shortcomings in its design or in the underlying hardware, for example:

The lack of paged virtual memory
A 2KB limit on the size of a message due to the limited address space provided by the underlying hardware
Inefficient IPC due to limited message size
No protection for ports
No way to notify the failure of a process to a dependent process without explicit registration of such dependencies
Networking not an area of emphasis in the original design

RIG port numbers were global, allowing any process to create or use them. Therefore, any process could send a message to any other process. However, RIG processes, which were single threaded, did have protected address spaces.

1.3.2. Accent

Richard Rashid was one of the people who worked on RIG. In 1979, Rashid moved to Carnegie Mellon University, where he would work on Accent, a network operating system kernel. Active development of Accent began in April 1981. Like RIG, Accent was also a communication-oriented system that used IPC as the basic system-structuring tool, or "glue." However, Accent addressed many of RIG's shortcomings.

Processes had large (4GB), sparse virtual address spaces that were linearly addressable.
There was flexible and powerful virtual memory management, which was integrated with IPC and file storage. The kernel itself could be paged, although certain critical parts of the kernel, such as I/O memory and the virtual memory table, were "wired" in physical memory.
Copy-on-write (COW) memory mapping was used to facilitate large message transfers. Based on experience with RIG, it was expected that most messages would be simple. There were optimizations for the common case.
Ports had the semantics of capabilities.
Messages could be sent to processes on another machine through an intermediary process, thus providing location transparency.

Memory-related API calls in Accent included functions for creating, destroying, reading, and writing memory segments, with support for copy-on-write. One may think of Accent as RIG enhanced with virtual memory and network-transparent messaging.

Accent was developed to support two distributed computing projects: SPICE (distributed personal computing) and DSN (fault-tolerant distributed sensor network). Accent was also the name of a food product (a spice) sold by Accent International, Inc. The only ingredient of this product was monosodium glutamate (MSG). In computing, one often abbreviates "message" as "msg".

Accent ran on PERQ computers, which were commercial graphics workstations. Three Rivers Corporation delivered the first PERQ in 1980. QNIX was a UNIX environment based on AT&T System V UNIX that ran under Accent on PERQ machines. Developed by Spider Systems, QNIX used its own microcode^[10] but ran in an Accent window managed by Accent's Sapphire window manager, with other Accent programs running alongside. A LISP machine (SPICE LISP) was also available for Accent, along with other languages such as Ada, PERQ, Pascal, C, and Fortran. PERQ could interpret bytecode in hardware, akin to latter-day mechanisms for Java.

^[10] The PERQ had soft-microcode, allowing its instruction set to be extended.

Within a few years, the future of Accent did not look promising. It needed a new hardware base, support for multiprocessors, and portability to other kinds of hardware. Accent also had difficulty supporting UNIX software.

Matchmaker

The Matchmaker project was started in 1981 as part of the SPICE project. Matchmaker was an interface-specification language intended for use with existing programming languages. Using the Matchmaker language, object-oriented remote procedure call (RPC) interfaces could be specified. The specification would be converted into interface code by a multitarget compiler. Matchmaker is readily comparable to the rpcgen protocol compiler and its language. The Mach Interface Generator (MIG) program, which is also used in Mac OS X, was derived from Matchmaker.

1.3.3. Mach

The sequel to Accent was called Mach, which was conceived as a UNIX-compatible Accent-inspired system. In retrospect, with respect to the first version (1.0) of Mach, one could consider Accent and RIG to be Mach versions 0.9 and 0.8, respectively.

When Mach was developed, UNIX had been around for over 15 years. Although the designers of Mach subscribed to the importance and usefulness of UNIX, they noted that UNIX was no longer as simple or as easy to modify as it once had been. Richard Rashid called the UNIX kernel a "dumping ground for virtually every new feature or facility."^[11] Mach's design goals were partially a response to the inexorably increasing complexity of UNIX.

^[11] "Threads of a New System," by Richard Rashid (Unix Review, August 1986, pp. 3749).

The Mach project started in 1984 with an overall goal of creating a microkernel that would be the operating system foundation for other operating systems. The project had several specific goals.

Provide full support for multiprocessing.
Exploit other features of modern hardware architectures that were emerging at that time. Mach aimed to support diverse architectures, including shared memory access schemes such as Non-Uniform Memory Access (NUMA) and No-Remote Memory Access (NORMA).
Support transparent and seamless distributed operation.
Reduce the number of features in the kernel to make it less complex, while giving the programmer a very small number of abstractions to work with. Nevertheless, the abstractions would be general enough to allow several operating systems to be implemented on top of Mach.
Provide compatibility with UNIX.
Address the shortcomings of previous systems such as Accent.

Mach was intended to primarily implement processor and memory management, but no file system, networking, or I/O. The "real" operating system was to run as a user-level Mach task. Written in C, the Mach kernel was also meant to be highly portable.

Mach's implementation used 4.3BSD as the starting code base. Its designers had RIG and Accent as references in the area of message-passing kernels. DEC's TOPS-20^[12] operating system provided some ideas for Mach's virtual memory subsystem. As Mach evolved, portions of the BSD kernel were replaced by their Mach equivalents, and various new components were added.

^[12] TOPS-20 was a descendant of the TENEX operating system.

When published in 1986, the original Mach paper hailed Mach as "A New Kernel Foundation for UNIX Development."^[13] While not everybody saw or sees it that way, Mach went on to become a rather popular system. From Apple's standpoint, the paper's title might as well have been "A NuKernel Foundation. . . ."

^[13] "Mach: A New Kernel Foundation For UNIX Development," by Mike Accetta, Robert Baron, William Bolosky, David Golub, Richard Rashid, Avadis Tevanian, and Michael Young. In USENIX Association Conference Proceedings (Atlanta, GA: USENIX Association, June 1986).

Initially the Mach designers presented four basic abstractions in the kernel.

A task is a container for the resources of one^[14] or more threads. Examples of resources include virtual memory, ports, processors, and so on.
^[14] It is possible to have a Mach task with zero threads, although such a task would not be very useful.
A thread is a basic unit of execution in a task. The task provides an execution environment for its threads, whereas the threads actually run. The various threads of a task share its resources, although each has its own execution state, which includes the program counter and various other registers. Thus, unlike a process in Accent, a Mach "process" is divided^[15] into a task and multiple threads.
^[15] Certain subsequent versions of Mach further subdivided a thread into an activation and a shuttle.
A port is similar to an Accent portit is an in-kernel message queue with capabilities. Ports form the basis for Mach's IPC facilities. Mach implements ports as simple integral values.
A message is a collection of data that threads in different tasks, or in the same task, can send to each other using ports.

Nomenclature

Avadis Tevanian, one of the inventors of Mach and Apple's Chief Software Technology Officer, told me the following history about how Mach was named. (Tevanian qualified the account as his best memory of an event that occurred two decades ago.) On a rainy day in Pittsburgh, Tevanian and some others were on their daily trek to lunch. As they were thinking of names for the yet unnamed Mach kernel, Tevanian, navigating around one of the numerous mud puddles, suggested the name "MUCK" in jest. MUCK was to stand for "Multi-User Communication Kernel" or "Multiprocessor Universal Communication Kernel." As a joke, Richard Rashid passed the name along to a colleague, Dario Giuse, who was Italian. Giuse inadvertently pronounced MUCK as "Mach," and Rashid liked it so much that the name stuck.

Another basic Mach abstraction is that of a memory object, which can be thought of as a container for data (including file data) mapped into a task's address space. Mach requires a paged memory-management unit (PMMU). Through its physical map (pmap) layer, Mach provides an excellent interface to the machine-dependent MMU facilities. Mach's virtual memory subsystem was designed to support large, sparse virtual address spaces and was integrated with IPC. In traditional UNIX, contiguous virtual memory space was implied, with the heap and the stack growing toward each other. In contrast, Mach allowed for sparse address spaces. Regions of memory could be allocated from anywhere in the address space. Memory could be shared for reading and writing in a structured manner. Copy-on-write techniques were used both to optimize copy operations and for sharing physical memory between tasks. The generalized memory object abstraction allowed for external^[16] memory pagers to handle page faults and page-out data requests. The source or target data could even reside on another machine.

^[16] Implies external to the kernelthat is, in user space.

FreeBSD's virtual memory architecture is based on Mach's.

One of CMU's important decisions was to provide all Mach software with unrestrictive licensing: free of distribution fees or royalties.

As noted earlier, Mach was neither meant to provide nor provided any file system, networking, or I/O capabilities. It was to be used as a service operating system to create other operating systems from. It was hoped that this approach would maintain simplicity and promote portability of operating systems. One or more operating systems could run on top of Mach as user-level tasks. However, real-life implementations deviated from this concept. Release 2.0 of Mach, as well as the rather successful Release 2.5, had monolithic implementations in that Mach and BSD resided in the same address space.

The Open Software Foundation^[17] (OSF) used Release 2.5 of Mach for providing many of the kernel services in the OSF/1 operating system. Mach 2.x was also used in Mt. Xinu, Multimax (Encore), Omron LUNA/88k, NEXTSTEP, and OPENSTEP.

^[17] The OSF was formed in May 1988 to develop core software technologies and supply them to the entire industry on fair and reasonable terms. It went on to have several hundred members from among commercial end users, software companies, computer manufacturers, universities, research laboratories, and so on. The OSF later became the Open Group and then Silicomp.

The Mach 3 project was started at CMU and continued by OSF. Mach 3 was the first true microkernel versionBSD ran as a user-space Mach task, with only fundamental features being provided by the Mach kernel. Other changes and improvements in Mach 3 included the following:

Kernel preemption and a real-time scheduling framework to provide real-time support
Low-level device support wherein devices were presented as ports to which data or control messages could be sent, with support for both synchronous and asynchronous I/O
A completely rewritten IPC implementation
System call redirection that allowed a set of system calls to be handled by user-space code running within the calling task
Use of continuations, a kernel facility that gives a thread the option to block by specifying a function (the continuation function) that is called when the thread runs again

Historically, arguments in favor of "true" microkernels have emphasized a greater degree of system structure and modularity, improved software engineering, ease of debugging, robustness, software malleability (e.g., the ability to run multiple operating system personalities), and so on. The intended benefits of microkernel-based operating systems such as Mach 3 were offset by the significant real-life performance problems that occurred due to reasons such as the following:

The cost of maintaining separate protection domains, including the cost of context switching from one domain to another (often, simple operations resulted in many software or hardware layers to be crossed)
The cost of kernel entry and exit code
Data copies in MIG-generated stub routines
The use of semantically powerful but implementation-heavy IPC mechanisms, even for same-machine RPC

Many operating systems were ported to the conceptual virtual machine provided by the Mach API, and several user-mode operating system interfaces were demonstrated to execute on top of Mach. The Mach-US symmetric multiserver operating system contained a set of server processes that provided generic system services such as local IPC; networking; and management of devices, files, processes, and terminals. Each server typically ran in a separate Mach task. An emulation library, which was loaded into each user process, provided an operating system personality. Such libraries used generic services to emulate different operating systems by intercepting system calls and redirecting them to the appropriate handlers. Mach emulators existed for BSD, DOS, HP-UX, OS/2, OSF/1, SVR4, VMS, and even the Macintosh operating system.

Richard Rashid went on to become the head of Microsoft Research. As noted earlier, Mach coinventor Avie Tevanian would be the Chief Software Technology Officer at Apple.

1.3.4. MkLinux

Apple and OSF began a project to port Linux to run on various Power Macintosh platforms, with Linux hosted on top of OSF's Mach implementation. The project led to a core system called osfmk. The overall system was known as MkLinux. The first version of MkLinux was based on Linux 1.3. It was released as MkLinux DR1 in early 1996. Subsequent releases moved to Linux 2.0 and beyond. One of the releases was incorporated into Apple's Reference Release.

MkLinux used a single-server approach: The monolithic Linux kernel ran as a single Mach task. Mac OS X uses a kernel base derived from osfmk and includes many MkLinux enhancements. However, all kernel components in Mac OS X, including the BSD portions, reside in the same address space.

Mach^Ten

The Mach^Ten product from Tenon Systems was introduced as an unobtrusive UNIX solution for Mac OS: It ran as an application atop Apple's operating system. Mach^Ten was based on the Mach kernel with a BSD environment. It provided preemptive multitasking for UNIX applications running within it, although the Mac OS execution environment remained cooperative multitasking.

Although the marriage of Mach, BSD, and Macintosh in Mach^Ten sounds similar to the latter-day Mac OS X, there is a critical difference in design and philosophy. Mac OS X was a continuation of NEXTSTEP technology in several ways. Apple provided legacy compatibility and ease of transition at two primary levels: through APIs such as Carbon and through the Classic virtualizer. In contrast, Mach^Ten was a logical opposite: Mac OS remained the first-class citizen, whereas UNIX ran in a virtual machine (UVM) that was implemented within a standard Macintosh application. The UVM provided a preemptive multitasking execution environment with a set of UNIX APIs (such as POSIX, including the standard C library and POSIX threads), a BSD-style networking stack, file systems such as UFS and FFS, RPC, NFS, and so on. Mach^Ten also included an implementation of the X Window System.

Although confined within a single application, Mach^Ten consisted of various subsystems similar to a full-fledged operating system. At the logically lowest level, an interface layer talked to Mac OS. The Mach kernel resided above this layer, providing services such as memory management, IPC, tasks, and threads. Other Mach^Ten subsystems that directly talked to the Mac OS interface layer included the window manager and the networking stack's ARP layer.

1.3.5. Musical Names

Apple's operating system strategy after acquiring NeXT was two-pronged: It would keep improving Mac OS for the consumer desktop market, and it would create a high-end operating system based on NeXT technology. The new systemcalled Rhapsodywould mainly be targeted toward the server and enterprise markets.

Besides chromatic aberrations such as Pink and Red, Apple had a string of musically inspired codenames for its operating system projects. Copland and Gershwin were named after Aaron Copland and George Gershwin, both American composers. Rhapsody in Blue is a famous work of Gershwin.^[18]

^[18] George Gershwin's brother Ira actually came up with the title Rhapsody in Blue.