System Support for Advanced Architectures

We're concerned with software system structures that make it possible to exploit the full potential of advanced architectures such as multiprocessors, wide-address machines, and high-bandwidth low-latency networks.

The SPIN project is concerned with increasing performance for resource-intensive applications, such as multimedia and databases. The key idea in SPIN is that of an adaptable kernel architecture; SPIN has an extensible microkernel, in which application-specific code can be embedded. An application can define new resources, which are split into a user-level component and a kernel-level component. The kernel contains mechanisms to permit the embedding of application-specific code (the kernel-level components) in a way that is completely protected. SPIN merges research in operating systems and programming languages, using trusted compilers and type-safe languages to verify the safety of these kernel-resident application components.

The performance potential of multiprocessors has proven to be elusive in practice. One important reason is that current multiprocessor operating system structures and facilities tend to be warmed-over rehashes of their uniprocessor predecessors. Multiprocessors create the opportunity and the need to re-think various aspects of operating system design. This has been a focus of our work for the past several years. Topics have included:

Lock management techniques for shared-memory multiprocessors.
Data structures for high-performance threads.
Kernel organization for high-performance interprocess communication on uniprocessors and multiprocessors.
Kernel abstractions providing effective support for the user-level management of parallelism.
The relationship of processor architecture and operating system design.

At the heart of much of this work is the observation that the basic role of the kernel must change as we move to multiprocessor systems. On uniprocessors, performance is enhanced by moving functionality into the kernel. On multiprocessors, the opposite is true: threads, thread scheduling, and interprocess communication should be managed entirely at user-level, with the kernel merely providing address spaces and occasionally reallocating processers among them.

Improved runtime support for specific classes of parallel scientific applications is another area that we are actively pursuing, as an outgrowth of our interest in system support. Topics include:

Support for particle-in-cell applications that facilitates the programming of these applications and provides automatic support for the important functions of data communication and load balancing.
The use of runtime compilation to improve performance: the efficient runtime detection of potential parallelism that is not amenable to a static analysis.
Communication scheduling in distributed memory machines. The overhead of message passing can be cut significantly by generating application-specific communication schedules that reduce the need for deadlock detection and flow control.
Runtime support for general parallel applications. Parallelism can be found either in terms of function (e.g., subroutines) or data (e.g., elements of an output matrix). To date, these two styles of parallelism have required distinct programming models and runtime support, so programmers have typically exploited only one or the other. We are developing a programming model and prototype that support both forms of parallelism simultaneously.

A third area of research involves object-oriented programming support for distributed and parallel systems. Over the past decade, four generations of object-oriented systems have been constructed here: Eden, Emerald, Presto, and Amber. A new system Opal, attempts to exploit the potential of wide-address architectures -- processors with 64 bits or more of addressing, such as the MIPS R4000 and the DEC Alpha.

In Opal, all applications execute in one address space. This facilitates sharing: a pointer means the same thing to all applications. The key point is that having a single address space does not compromise protection: each application executes in a private protection domain; the fact that an application can generate an address does not mean that it can necessarily read or write that address. Protection domains are composed of multiple segments; segments are the basic unit of sharing.

Achieving low-latency cross-machine communication using the coming generation of high-bandwidth networks (specifically ATM networks) is another area of current interest.

Principal Investigators: Bershad, Lazowska, Levy, Zahorjan

webmaster@cs.washington.edu