Goals

Nemesis is an operating system designed to support a mixture of time-sensitive (e.g. multimedia) and standard applications. It achieves this by:

1.

providing applications with explicit guarantees for real resources,

2.

enabling applications to execute the vast majority of of operations themselves, and then

3.

making applications responsible for their behaviour.

In terms of CPU allocation, for example, this strategy is realised by means of a soft real-time scheduling algorithm and the use of scheduler activations[Anderson92]. Once an application has sufficient knowledge to observe exactly what occurs in the present, and to predict what will occur in the future, it may choose its operational parameters with confidence. This fact has been successfully demonstrated in the past[Hyden94,Roscoe95,Leslie96].

Nemesis has been constructed as a single address space operating system (SASOS); i.e. translations from virtual to physical addresses are shared between all executing domains. This is in contrast to typical operating systems such as Unix, VMS and Windows NT, where each executing process (or task) sees an individual virtual address space. Note that global translations do not in any way imply any lack of inter-domain protection: all domains execute in some protection domain which contains a set of access rights for any given page. Thus there is a clear separation between the concepts of protection and of translation .

The decision to make Nemesis a SASOS was motivated by a number of clear benefits:

• Lower Context Switch Times.
  The support of applications which have temporal constraints requires fine-grained multiplexing of the CPU. This leads to more context switches. In a SASOS, a single virtual address translation structure can be used for all domains, and hence need not be context switched. While this itself can only give a modest improvement, there is potentially a huge additional benefit from improved cache and TLB performance.
• Reduced Data Copying.
  Many continuous media applications deal with streams of data. In the general case this data may require processing by a number of different domains. Rather than provide special purpose `bulk transfer' IPC mechanisms such as those implemented by operating system microkernels like Mach[Young87], EROS[Shapiro96] and L4[Liedtke96a], a SASOS can simply share data between different domains. This means that IPC times are not dominated (or even affected) by the amount of data which is logically transferred. One- or zero-copy network stack implementations are also more easily achieved.
• Rich Sharing of Text.
  One important factor in the provision of Quality of Service (QoS) is the independence of scheduled tasks from one another. This may most conveniently be achieved by enabling each application to execute as much of its own code as possible. This provides true application accountability, aiding resource management and banishing ``QoS crosstalk''[Roscoe95]. In a SASOS, sharing text is trivial.

Nemesis is almost entirely composed of shared library code. The linkage model chosen is that of closures [Roscoe94], which usefully allow for the sharing of program text among different instantiations with differing state. This model allows for very efficient sharing of code (one additional memory dereference per operation) at a fine granularity. It effectively allows nearly all functions traditionally considered ``kernel'' or ``server'' features to be executed by applications themselves. The resultant operating system structure has been described as ``vertically integrated''[Barham96].

This strategy of forcing applications to execute nearly all operations themselves also helps achieve another of the Nemesis goals: extensibility . While there is a large amount of shared library code available to applications, there are no requirements that they make use of these standard implementations. Nemesis uses an interface definition language (IDL) to help demarcate the boundaries between interface and implementation . The operating system defines the system interfaces and provides default implementations, but allows applications choose the actual implementation they use.

The recent emergence of 64-bit microprocessor architectures has prompted the development of a number of new single address space operating systems including Angel[Murray93], Opal[Chase94] and Mungi[Heiser94]. All of these, however, are motivated by the potential inherent in a wide address space for the support of distributed shared virtual memory (DSVM) or persistent memory mapped objects

Nemesis does not view either of these as fundamental operating system issues. They represent choices which should be made by individual applications, not mandated by the operating system. The Nemesis operating system securely multiplexes resources between domains; applications are responsible for the rest.

In terms of the memory system, this means that while resource allocation (viz. virtual and physical address allocation) needs to be carried out in a secure and centralised manner, little else does. Setting up protection, virtual address mappings or even handling memory faults are application tasks.