Paper Evaluations: 06-05-2000

Mon, 5 Jun 2000 21:49:12 -0700 (PDT)

Title: "Exokernel: An Operating System Architecture for
Application-Level Resource Management"

Exokernel is an operating system architecture in which the
abstractions as virtual memory and interprocess communication are
implemented in the application level by untrusted software. In this
architecture, a minimal kernel securely multiplexes all the accesses
to hardware resources. Library operating systems implement the
abstractions in the application level, and access the hardware through
calls to the kernel low-level interface.

An exokernel separates protection from management through its
low-level interface, so that the library operating systems are
isolated from each other. The technique used to track ownership is
secure bindings that binds library operating systems to machine
resources. A library holding a resource binding may be asked by the
exokernel to revocate the resource, and the visible resource
revocation technique used permits a library to participate in the
revocation process. If a library does not respond to a revocation
request, then a abort protocol is used to force resource revocation.

A exokernel and a library operating system prototypes were
implemented, called Aegis and ExOS, respectively. The performance was
compared with the Ultrix operating system, which implements a
monolithic kernel. The results show that in most cases, the prototype
outperforms the Ultrix implementation, sometimes by one or more orders
of magnitude. The main reasons are: the high-performance low-level
exokernel interface, the reduction in the number of kernel
transitions, and the implementation in the application-level of new
features that are not provided by the operating system.

The idea of operating systems abstractions implemented in user space
is also proposed in microkernel architectures, which provide a small
set of functionalities. Exokernel, however, provides fewer
functionalities, and hence an even thinner kernel. In my opinion, this
is a very interesting proposal, since, in this architecture, it is
possible to enhance applications by implementing appropriate
libraries. This architecture is particularly good for domain-specific
applications requiring high-performance. For these applications,
developers would not mind to implement a system using such a low-level
interface, if a good performance is obtained. For desktops, however,
it would be interesting to provide higher-level tools, so that users do
not need to deal with hardware details.


Title: "Extensibility, Safety and Performance in the SPIN Operating

SPIN is a general-purpose operating system that was designed to
provide extensibility, safety, and high-performance. In SPIN,
extensions can be loaded into the kernel at any time. Extension
modularity is enforced by the programming language. Thus, modules are
isolated from one another with low-cost. Extensions are inside logical
protection domains, and are accessed through exported interfaces
protected by the operating system. A cross-domain call is resolved by
an in-kernel dynamic linker, and hence occurs with the overhead of a
procedure call. This is the case also for event handling. Extensions
are executed as responses to system events, and are also dispatched
with the overhead of a procedure call.

SPIN and its extensions are written in Modula-3, and depend on this
language safety and encapsulation mechanisms for protection. A
protection model is defined for SPIN to control the access to
resources. All kernel resources are referenced by capabilities, and a
resource can be a system object, an interface, or a collection of
interfaces. Capabilities are implemented in SPIN as pointers,
decreasing the overhead for passing it across an interface, or
dereferencing it. Protection domains are also defined to determine the
set of accessible names available to an execution environment. A
domain is named by a capability, and corresponds to one or more object
files with one or more exported interfaces.

Performance was evaluated by executing some benchmarks. SPIN
performance was also compared with Mach and OSF/1 operating systems,
which are a microkernel and a monolithic implementations,
respectively. The evaluation shows some interesting results. The
in-kernel protected calls in SPIN have a very low overhead. Thus, the
use of in-kernel extensions is encouraged. In terms of virtual memory,
SPIN was faster in all benchmarks. This is due basically to the
implementation using extensions. For network measurements,
reliable bandwidth obtained was roughly the same for SPIN and OSF/1,
while latency was lower for SPIN.

SPIN and Exokernel are two operating system architectures based on the
idea of extensibility by untrusted software. Compared to the exokernel
architecture, SPIN kernel provides more functionalities, and hence
abstracts more the hardware than the exokernel does. Moreover,
extensions in SPIN permits further improvements over existing
operating system abstractions without increasing significantly system
overhead due to fast in-kernel protected calls. In my opinion, SPIN
seems more portable and easier to extend in terms of the operating
system functionalities.

--Flavio Junqueira.

Flavio Paiva Junqueira, PhD Student
Department of Computer Science and Engineering
University of California, San Diego

Office location: AP&M 4349 e-mail: