Grasshopper: An orthogonally persistent operating system † Alan Dearle, * Rex di Bona, * James Farrow, * Frans Henskens, * Anders Lindström, * John Rosenberg, † Francis Vaughan † Department of Computer Science University of Adelaide S.A., 5001, Australia {al,francis}@cs.adelaide.edu.au * Department of Computer Science University of Sydney N.S.W., 2006, Australia {rex,matty,frans,anders,johnr}@cs.su.oz.au Abstract 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 and 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. 1. Introduction The aim of the Grasshopper project is to construct an operating system that supports orthogonal persistence [3]. This begs two questions, what is orthogonal persistence and why does it require support from an operating system? The two basic principles behind orthogonal persistence are: • that any object may persist (exist) for as long, or as short, a period as the object is required, and • that objects may be manipulated in the same manner regardless of their longevity. The requirements of a system which supports orthogonal persistence can be summarised as follows. • Uniform treatment of data structures: Conventional programming systems require the programmer to translate data resident in virtual memory into a format suitable for long term storage. For example, graph structures must be flattened when they are mapped onto files or relations; this activity is both complex and error prone. In persistent systems, the programmer is not required to perform this mapping since data of any type with arbitrary longevity is supported by the system. • Location independence: To achieve location independence, data must be accessed in a uniform manner, regardless of the location of that data. This principle is the cornerstone of virtual memory – the programmer does not have to be concerned whether the data is in RAM or on disk; the data is accessed in a uniform manner. In distributed persistent systems, location independence is extended to the entire computing environment by permitting data resident on other machines to be addressed in the same manner as local data [14, 15, 20, 40, 41]. This approach is also followed in distributed shared memory systems [36].