Home   Info   DevZone   Wiki  
UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
Grasshopper ] [ not logged in ] [ Web: Imported ] goto:  options
[ get info on or edit ] login or new user ] [ list of topics, hubs & nodes, or recent changes ]

Grasshopper is an operating system that provides support for OrthogonalPersistence, i.e. objects are transparently stored regardless of their type.

Storage in a Grasshopper system is provided by containers, which replace both address spaces and file systems.

Containers can share data through the use of container mappings where regions of one container can be mapped to a similar region in a different container. This can be done recursively so that containers can map regions that contain mappings from other containers.

Data stored in a container is supplied by a manager which is responsible for maintaining a consistent and recoverable stable copy of the data represented by the container. They are also responsible for maintaining the data when it is not resident in RAM.

A manager is invoked whenever the kernel detects a memory access fault to data stored in the container it manages. The kernel is responsible for identifying which manager should be requested to supply the data. The manager delivers the data to the kernel which then arranges the hardware translation tables in such a way that the data is visible at an appropriate address in the container.

In Grasshopper, the manager is the only mechanism by which data migrates from stable to volatile storage. Grasshopper has no file system in the conventional sense, each manager is free to manage the data in the way it sees fit.

Processes or threads (called loci in Grasshopper) execute within a host container, and can only address the data visible in the container in which it is executing. Any number of loci can execute within a given container. Loci may change their host container by invoking a different container. This enables loci to migrate from container to container, bringing their state along with them.

All loci executing within a container see the address space of that container and share that space with all other loci executing in the container.

Access to containers and loci is controlled by capabilites. A capability consists of a unique name for an entity, a set of access rights related to that entity and rights pertaining to the capability itself, in particluar whether the capability can be copied. An operation can only be performed if a valid capability for that operation is presented.

In Grasshopper, every container and locus can have an associated list of capabilities. At any time a locus has access to all the capabilities in it's own list plus all the capabilites in it's host container's list.

Each manager implements a stabilise operation which creates a consistent copy of the data on a stable medium. However, the managers cannot stabilise independently and still provide global consistency. A list of dependencies between containers and loci is maintained and the managers are stabilised in groups. The kernel requests the appropriate managers to stabilise and once they have done so stabilises it's own state and finally commits a descriptor block that describes the new state to stable storage.

This mechanism allows a Grasshopper kernel to persist even when the machine is not operating, after the initial boot an entire self-consistent state is loaded and continues execution.

References

Grasshopper Home - http://www.gh.cs.su.oz.au/Grasshopper/

Grasshopper: An orthogonally persistent operating system - http://www.gh.cs.su.oz.au/Grasshopper/Papers/GH10/gh10.html




Content of these pages are owned and copyrighted by the poster.
Hosted by: