04-12-2012, 11:40 AM
Grass hopper os
Grass hopper.docx (Size: 101.29 KB / Downloads: 20)
Abstract
This paper describes Grasshopper, an operating
system designed to provide generic mechanisms capable
of being tailored to support a wide range of persistence
paradigms. A constraint placed on this design is that the
system must be implementable on conventional
architectures which support paged virtual memory.
In this paper the basic system abstractions relating to
addressing environments, processes, and protection are
described. It is shown that these provide explicit support
for distributed persistent objects and processes, stability,
and access control. At the same time the system provides
the flexibility to allow user implementation of alternate
object management techniques.
Related work
Attempts to build persistent systems above
conventional operating systems have encountered
difficulties, caused in part by the fact that these operating
systems were not designed with persistence in mind. For
example, the developers of Napier88 have
experienced unpredictable performance degradation
apparently caused by bottlenecks in Unix. In-depth
knowledge of the internal structure of the operating
system is required to make any substantial performance
improvements.
Even researchers using ‘open’ operating systems such
as Mach [1] have experienced difficulties brought about
by the inability to control certain operating system
functionality. For example, the distributed Napier group
[23] had problems with lack of control over page discard.
Other projects such as Monads [19] have taken the
opposite approach and have developed purpose-built
hardware and a new operating system which operates
above it. This approach shows much promise in that
appropriate architectures can be provided thus avoiding
the constraints mentioned above. However, there are
major disadvantages, such as the cost of development of
new hardware, the time this development takes, and the
inability to make the operating system and persistent
applications readily available to other research groups.
An intermediate approach is to develop a new
operating system with provides support for persistence,
but which operates on top of conventional hardware.
Aims and goals of this project
In this project we aim to design and implement an
operating system kernel which provides generic
mechanisms capable of being tailored to support a wide
variety of persistence paradigms,
In this sense Grasshopper has similar aims to the
micro-kernel projects [1, 4], but with a specific
orientation towards support for persistence.
The Basic abstractions
An operating system is largely responsible for the
control and management of two entities: objects, which
contain data and processes, the active elements which
manipulate these objects. One of the most important
considerations in the design of an operating system is the
model of interaction between these entities. There are
two principal models of computation which we call the
out-of-process and the in-process models.
The out-of-process model aligns processes with
objects. Communication between processes aligned with
different objects is achieved through the use of messages.
The in-process model provides for processes which move
between objects. Processes access objects by invoking
them. The invoke operation effectively causes a
procedure call to code within the object. By executing
this code the process may access other data stored within
the object. It is interesting to note that, whilst the out-ofprocess
model cannot be used to efficiently simulate any
other computational models, the in-process model is
more flexible. For instance, it can easily simulate the
out-of-process model by associating a message passing
process with every object. The in-process model can also
be used to implement other addressing paradigms, for
instance distributed memory [10].
Containers
Containers are persistent entities which abstract over
storage and thus provide the environment in which loci
execute. A container may consist entirely of its own
data, or may (recursively) have one or more regions of
other containers mapped onto parts of it. Information
about such mappings is maintained by the kernel.
A locus executing within a container accesses the data
stored in it using container addresses. The container
address of a word of data is its offset relative to the start
of the container in which it is accessed.
Summary
The Grasshopper system provides support for three
basic abstractions, namely containers, loci and
capabilities. The storage abstraction provided by
containers both defines an addressing environment for
loci and simplifies sharing of data between loci through
the use of container mappings. By associating a manager
with a container, the system facilitates the implementation
of container-specific stability protocols, distributed
coherence protocols, and unconventional addressing
techniques such as those involving pointer swizzling.
The in-process model of computation adopted by the
project allows a locus to move naturally between
containers without the overhead of accompanying process
switches. Use of the in-process model is also expected to
simplify the implementation of distributed access to
containers.