Web site: os.dcs.st-and.ac.uk/GH/Grasshopper.html (not active)
Desktop environment: CLI
Based on: independent
The last version | Released: 1992 (?)
Grasshopper – a distributed OS with Orthogonal Persistence. The Grasshopper operating system project ran in the Universities of Sydney and Adelaide, Australia in the early nineties.
Despite the fact that the basic idea behind orthogonal persistence is very simple, research groups are finding it extremely hard to develop scalable and efficient persistent stores. One of the major difficulties derives from the fact that persistence provides a fundamentally different model of computing from that supported by conventional operating systems. It is therefore not surprising that we are finding that such operating systems are inappropriate for persistent systems research. In this project we are investigating the requirements of an operating system to support persistence and propose to design and construct a new operating system, known as Grasshopper, which has explicit support for persistent systems. This operating system is implemented on standard workstation hardware.
For ten years researchers have been attempting to construct programming language systems that support orthogonal persistence above conventional operating systems. This approach has proven to be poor; researchers invariably construct a complete abstract machine above the operating system with resulting loss of efficiency. This paper describes a new approach, the construction of an operating system designed to support orthogonal persistence. The operating system, Grasshopper, relies upon three powerful and orthogonal abstractions: containers, loci an capabilities. Containers provide the only abstraction over storage, loci are the agents of change, and capabilities are the means of access and protection in the system. This paper describes these three fundamental abstractions of Grasshopper, their rationale and how they are used.
The Grasshopper operating system provides explicit support for orthogonal persistence. A consequence of this is that the kernel itself must, in part, be persistent. To conform to the model of persistence in Grasshopper, the kernel persistent store must provide a means to stabilize entities independently of each other and must also be able to maintain an arbitrary number of versions for each entity. The design of the kernel persistent store is constrained by the need to be very efficient and to intrude as little as possible on the code using the store. Entities in the store reside at fixed, unique virtual addresses by which they are identified. This allows standard demand paging techniques are used making the store efficient and unobtrusive. Rather than provide for the independent stabilization of individual data structures, the store provides regions, which are variable-size sets of possibly noncontiguous virtual pages, that may be stabilized independent of each other and that may have many versions. These regions, called persistent arenas, are used by higher-level software as pools for the allocation of smaller data structures that must logically be stabilized together.