Abstract: SOS (SOMIW Operating System) is the result of a four-year effort at INRIA to define an object-oriented operating system. SOS provides support for arbitrary, user-defrned, typed objects. The system implements object migration; this mechanism is generic, but can be tailored to specific object semantics thanks to the prerequisite and upcall concepts. SOS also supports Fragmented Objects (FOs), i.e. objects the representation of which spreads across multiple address spaces. Fragments of a single FO are objects that enjoy mutual communication privileges. A fragment acts as a proxy, i.e. a local interface to the FO. All the other mechanisms of SOS are built upon these basic abstractions. Thanks to prerequisites, migration of data may cause the migration and dynamic type-checking and linking of the corresponding code. A distributed object manager, an object storage service, a naming service, as well as a protocol toolbox and some applications, have been built as FOs. This paper gives a detailed account of the architecture and design decisions of the SOS prototype on UNIX. ruy'e examine both good decisions and problems. The basic good decision is our simple object model, and its ability to map user-defrned semantics (policy decisions) on system-implemented mechanisms. The most important problem is the dynamic nature of Fragmented Objects, and inadequate support for them.

Abstract: We describe an implementation of a fine-grain adaptive scheduling mechanism, based on software feedback. Conventional scheduling makes job assignment exclusively a function of time. We broaden the meaning of the term "scheduling" to include job assignment as a function of a sequence of events, such as timer interrupts, I/O operations, queue overflodunderflow, and system call traps. Our implementation of software feedback in the Synthesis operating system is analogous to the hardware phase locked loop. Very low overhead context switches and scheduling cost (a few microseconds on a 68020-based machine) makes this implementation useful to practical applications such as digital signal processing. Since scheduling actions and policy adjustments occur at very frne granularity (sub-millisecond intervals), Synthesis adaptive scheduling is very sensitive. Interesting applications of fine-grain adaptive scheduling include I/O device management, real-time schedul- ing, and distributed adaptive scheduling.

Abstract: When implemented in a concurrent language, a window system can be concise. If its client programs connect to the window system using an interface defined in terms of communication on synchronous channels, much of the complexity of traditional event-based interfaces can be avoided. Once that interface is specified, complex interactive programs can be assembled, not monolithically, but rather by connecting, using the same techniques, small self-contained components that each imple- ment or modify elements of the interface. In partic- ular, the window system itself may be run recur- sively to implement subwindows for multiplexed applications such as multi-frle text editors. This is the software tool approach applied to windows.

Abstract: Hypertext is concerned with on-line documentation. Over the past two years, interest in hypertext has grown dramatically and there has been a corresponding explosion in the number of hypertext systems, journal articles and, indeed, hypertext experts. One of the deficiencies of many of today's hypertext systems is that they are closed systems: they do not work well with their fellow tools. Though it may be possible to exchange information with other tools, this needs to be done via conversion utilities or the like. As Meyrowitz Ir9s7] highlighted in his influential contribution to the Hypertext 87 conference, this drains the blood out of the hypertext system. If hypertext systems are to realise their full potential, they must aim for a seamless interface with other tools, thus making the whole greater than the sum of the parts. Such a philosophy is, of course, one of the cornerstones of UNIX. The purpose of this paper is to describe how the Guide hypertext system has been designed to exploit the UNIX environment. The word "seamless," like the world "user-friendly," is wantonly applied to almost all software: it is fast becoming a noise-word. If we are to stick to the true meaning of seamlessness, Guide cannot claim to have attained it. Nevertheless the claim of this paper is that it has been able to gain a lot of value from @ Computing Systems, Vol. 2 . No. I . Winter 1989 37 interchanging information with its UNIX environment. It is no use writing a paper about integration unless readers understand what is being integrated. Since some readers will be unfamiliar with hypertext in general and Guide in particular, so we shall introduce these frrst.

Abstract: Executable frles in the Ninth Edition of the UNIX system contain small amounts of unused space, allowing small code sequences to be added to them without noticeably affecting their functional- ity. A program fragment that looks for binaries and introduces copies of itself into their slack space will transitively spread like a virus. It could, like the Trojan Horse, harbor Greeks set to attack the sys- tem when run with enough privilege. I wrote such a program (without the Greeks) and ran several informal experiments to test its charac- teristics. In one experiment, the code was planted on one of Bell Labs' computers and spread in a few days through our Datakit network to about forty machines. The virus escaped during this test onto a machine running an experimental secure UNIX sys- tem, with interesting (and frustrating for the system's developers) consequences. To fit in the small amount of space available viruses of this sort must be tiny, and consequently timid. There are ways to write similar viruses that are not space-constrained and can therefore spread more aggressively and harbor better-armed Greeks. As an

Abstract: Automatic text formatters usually pro- duce poor page layouts: pages may have different lengths, widow lines abound, and figure placement is hard to control and often wrong. This paper describes a different approach to page makeup. \We add to the output of a text formatter extra informa- tion that tells how various elements of the document should appear on the page. A postprocessor uses this information to make all pages the same height, prevent the creation of widow and orphan lines, place footnotes, and float figures to a suitable posi tion on an appropriate page. V/e have implemented such a postprocessor for text processed by the TROFF text formatter. The current version handles these page-makeup tasks for one- and two-column text. Versions of the program have been used to produce camera-ready copy for at least six books and several journal articles. The authors typeset this paper using the software it describes.

Abstract: Type parameterization is the ability to defrne a type in terms of another, unspecifled, type. Versions of the parameterized type may then be created for several particular parameter types. A language supporting type parameterization allows specification ofgeneral container types such as list, vector, and associative array where the specific type of the elements is left as a parameter. Thus, a parameterized class specifies an unbounded set of related types; for example: list of int, list of name, list of shape, etc. Type parameterization is one way of making a language more extensible. In the context of C++, the problems are 1. Can type parameterization be easy to use? 2. Can objects of a parameterized type be used as efficiently as objects of a "hand-coded" type? 3. Can a general form of parameterized types be integrated into C++? 4. Can parameterized types be implemented so that the compilation and linking speed is similar to that achieved by a compilation system that does not support type parameterization? 5. Can such a compilation system be simple and portable? @ Computing Systems,Yol.2. No. I . Winter 1989 55 56 A design is presented for which the answer to all of these questions is yes. The implementation of this scheme is a fairly simple extension of current C++ implementations. v/ARNING: The scheme for providing parameterized types described here is not implemented. It is not part ofthe C++ language, nor is there any guarantee that it ever will be.

Abstract: In this paper we describe Durra, a language designed to Support PMS-level programming, and its runtime environment. Users of networks of heterogeneous processors are concerned with allocating specialized resources to tasks of medium to large size. They need to create processes, which are instances of tasks, allocate these processes to processors, and specify the communication patterns between processes. These activities constitute Processor-Memory-Switch (pMS) Level Programming, ín contrast with traditional programming activities, which take place at the Instruction Set Processor (ISP) Level. This work is sponsored by the U.S. Department of Defense. The views and conclusions contained in this document are solely those ofthe author(s) and should not be interpreted as representing ofrcial policies, either expressed or implied, of Carnegie Mellon University, the U.S. Air Force, the Department of Defense, or the U.S. Government. @ Computing Systems, Vol. 2 . No. I . Winter 1989 An application or PMS-level program is written in Durra as a set of msk descriptions and type declarations that prescribes a way to manage the resources of a heterogeneous machine network. The application describes the tasks to be instantiated and executed as concurrent processes, the types of data to be exchanged by the processes, and the intermediate queues required to store the data as they move from producer to consumer processes. The environment consists of three active components: the application tasks, the Durra server, and the Durra scheduler. After compiling the type declarations, the component task descriptions, and the application description, the application can be executed by starting an instance ofthe server on each processor, starting an instance ofthe scheduler on one of the processors, and downloading the component task implementations (i.e., the programs) to the processors. The scheduler receives as an argument the name of the file containing the scheduler program generated by the compilation of the application description. This step initiates the execution of the application. l. Programming Heterogeneous

Abstract: The throughput of a disk subsystem is critical to the performance of a computer system. The 4.3BSD UNIX operating system provides a good example for looking at the heuristics that are used to optimize the positioning of the read-write heads of a disk drive. In this paper we investigate the heuristics used in the BSD hp disk driver. These heuristics are driven by three parameters that can be changed by the system manager. We investigate the interaction of these parameters with the BSD fast file system. This provides a way to see the effects of the BSD fast frle system. Finally we present the results of monitoring three active frle systems during day-to-day use, to see what effect these heuristics can have. @ Computing Systems,Yol.2. No. 3 . Summer 1989 251

Abstract: The lcon programming language pro- vides a rich variety of data structures with sophisti- cated facilities: sets of arbitrary values, tables with associative lookup, lists with positional and deque access mechanisms, and records that extend the type repertoire ofthe language. Instances ofthese structures are created at run-time and grow and shrink as values are added to or removed from them. Storage management is automatic. This paper describes these structures and their use in combination with lcon's goal-directed evaluation mechanism. Examples illustrate the use of pointer semantics and heterogeneity and how the natural geometrical interpretation of structures like trees and graphs in the problem domain is imaged in the programming domain.

Abstract: There is nothing mysterious about computer viruses. A working, but easily observable, virus can be written in a few lines of code. Although particular virus attacks may be guarded against, no general defense within one domain of reference is possible; viruses are a natural consequence of stored-program computation. Like other hazards of technology, their threat may be mitigated by cautious behavior and community sanctions. I. The principle I intend to demonsftate a simple, yet realistic, computer virus for people who may be curious but who have not been motivated to dabble in this shady field. Nothing here will edify folks bent on mischief. The example is made for clarity; it makes no malign effort to hide in obscure recesses of a computer system. It has been expressed in a highly accessible language-the shell language of UNIX systems. Thus it may be understood without resort to "microscope and tweezers." [Eichen & Rochlis 1988] For good cause, it has not been tested. Ostensibly as a public service, but probably more to establish priestly mystery, writers about viruses usually omit the details.

Abstract: Remote Procedure Calls (RPC) are an established mechanism for coordinating activity between multiple processors in a distributed system. Their efficient use in Interprocess Communication (IPC) is difficult because underlying network proto- cols can have a great effect on system performance, especially when the IPC is within the same proces- sor. This problem is compounded if the distributed system must work simultaneously over several forms of interconnect. Designing an efficient solu- tion for one medium may make accommodating another awkward or impractical, while designing a general solution for all may not take full advantage of any specifrc medium. This paper describes an enhanced remote procedure call model of interprocess communication that is generally efficient for many types of network, even nontraditional ones. It is based on optional hints supplied by the client of an operation, which enable medium-specifrc optimizations in a uniformly struc- tured interface. The model supports dynamic rebinding of communications protocols, which is necessary for the efficient treatment of migratable system objects.

Abstract: Mach is a new operating system tar- geted for distributed and multiprocessor environ- ments. Mach contains 4.3BSD compatibility code that, unlike the Mach kernel proper, runs only on a single processor, thus presenting a performance bottleneck to a multiprocessor system. Pieces of the 4.3BSD compatibility code were selectively parallel- ized to reduce this bottleneck. Signifrcantly improved multiprocessor and multi-user perfor- mance was achieved using minimum modifrcation of existing data structures and algorithms. A frame- work was left in place for future parallelization enhancements.

Abstract: Clouds is a native operating system for a distributed environment The Clouds operating system is built on top of a kernel called Ra Ra is a second generation kernel derived from our experi- ence with the first version of the Clouds operating system Ro is a minimal, flexible kernel that pro- vides a framework for implementing a variety of distributed operating systems This paper presents the Clouds paradigm and a brief overview of its first implementation We then present the details of the Ro kernel, the rationale for its design, and the system services that consti- tute the Clouds operating system