Fig 15 - uploaded by Malcolm Phillip Atkinson
Content may be subject to copyright.
Source publication
Persistent programming systems are designed as an implementation technology for long lived, concurrently accessed and potentially large bodies of data and programs, known here as persistent application systems (PASs). Within a PAS the persistence concept is used to abstract over the physical properties of data such as where it is kept, how long it...
Citations
... Explicitly interacting with storage mechanisms outside the control of the application might result in hard to maintain code bases, as correct handling of interfacing, typing, and concurrency have to be resolved. Persistent programming languages can offer a much higher abstraction when interacting with persistent data [Atkinson et al. 1982;Bläser 2007;Hosking and Chen 1999;Morrison et al. 2000]. They often rely on the concept of orthogonal persistence introduced by Atkinson et al. [1983] and further described in more detail by Atkinson and Morrison [1995]. ...
Emerging persistent memory in commodity hardware allows byte-granular accesses to persistent state at memory speeds. However, to prevent inconsistent state in persistent memory due to unexpected system failures, different write-semantics are required compared to volatile memory. Transaction-based library solutions for persistent memory facilitate the atomic modification of persistent data in languages where memory is explicitly managed by the programmer, such as C/C++. For languages that provide extended capabilities like automatic memory management, a more native integration into the language is needed to maintain the high level of memory abstraction. It is shown in this paper how persistent software transactional memory (PSTM) can be tightly integrated into the runtime system of Haskell to atomically manage values of persistent transactional data types. PSTM has a clear interface and semantics extending that of software transactional memory (STM). Its integration with the language’s memory management retains features like garbage collection and allocation strategies, and is fully compatible with Haskell's lazy execution model. Our PSTM implementation demonstrates competitive performance with low level libraries and trivial portability of existing STM libraries to PSTM. The implementation allows further interesting use cases, such as persistent memoization and persistent Haskell expressions.
... PS-algol had no support for concurrency (other than at database level), which often caused problems. Napier88 Napier88 [21, 48] consisted not only of a language, but a complete self-contained persistent system, incorporating the whole language support within a strongly typed persistent store. It provides a pre-populated strongly typed stable store containing libraries for handling concurrency, distribution and user transactions, and a complete programming environment.Figure 8.1 displays the layered architecture of the Napier88 system. ...
For almost 30 years, computer memory systems have been essentially the same: volatile, high speed memory technologies like SRAM and DRAM used for cache and main memory; magnetic disks for high-end data storage; and persistent, low speed flash memory for storage with low capacity/low energy consumption requirements such as embedded/mobile devices. Today we watch the emergence of new non-volatile memory (NVM) technologies that promise to radically change the landscape of memory systems. In this work we assess system-level latency and energy impacts of a computer with persistent main memory using PCRAM and Memristor. The experimental results support the feasibility of employing emerging non-volatile memory technologies as persistent main memory, indicating that energy improvements over DRAM should be significant. This study has also compared the development and execution of applications using both a traditional filesystem design and a framework specific of in-memory persistence (Mnemosyne). It concludes that in order to reap the major rewards potentially offered by persistent main memory, it is necessary to take new programming approaches that do not separate volatile memory from persistent secondary storage.
... In an orthogonally persistent system, any data value can be made persistent, without exception, regardless of its type, how and when it was created, etc. PS-algol [3] was the first language to have orthogonal persistence, while Napier88 [23] was the first language to model persistence within a sophisticated typing regime, including parametric polymorphism, existential data typing, and controlled dynamic typing within a static context. Although technically innovative, these languages were not widely adopted, perhaps due in part to their closedworld model. ...
The persistent programming systems of the 1980s offered a programming model that integrated computation and long-term storage. In these systems, reliable applications could be engineered without requiring the programmer to write translation code to manage the transfer of data to and from non-volatile storage. More importantly, it simplified the programmer's conceptual model of an application, and avoided the many coherency problems that result from multiple cached copies of the same information. Although technically innovative, persistent languages were not widely adopted, perhaps due in part to their closed-world model. Each persistent store was located on a single host, and there were no flexible mechanisms for communication or transfer of data between separate stores. Here we re-open the work on persistence and combine it with modern peer-to-peer techniques in order to provide support for orthogonal persistence in resilient and potentially long-running distributed applications. Our vision is of an infrastructure within which an application can be developed and distributed with minimal modification, whereupon the application becomes resilient to certain failure modes. If a node, or the connection to it, fails during execution of the application, the objects are re-instantiated from distributed replicas, without their reference holders being aware of the failure. Furthermore, we believe that this can be achieved within a spectrum of application programmer intervention, ranging from minimal to totally prescriptive, as desired. The same mechanisms encompass an orthogonally persistent programming model. We outline our approach to implementing this vision, and describe current progress. Comment: Submitted to EuroSys 2006
... Napier88 attempted to explore the limits of orthogonal persistence by incorporating the entire language support environment within a strongly typed persistent store [12,21,[26][27][28][29][30]. The research produced the first integrated, self-contained, type-safe persistent environment. ...
The social and economic importance of large bodies of programs and data that are potentially long-lived has attracted much attention in the commercial and research communities. Here we concentrate on a set of methodologies and technologies called persistent programming. In particular we review programming language support for the concept of orthogonal persistence, a technique for the uniform treatment of objects irrespective of their types or longevity. While research in persistent programming has become unfashionable, we show how the concept is beginning to appear as a major component of modern systems. We relate these attempts to the original principles of orthogonal persistence and give a few hints about how the concept may be utilised in the future. Comment: 2nd International Conference on Object Databases (ICOODB 2009), Zurich, Switzerland. pp. 1-22
... Here we assume that such a mechanism is available, and focus on one particular area of functionality: that of storage. Previously we have been involved in building a number of object stores—including Napier88 (Morrison, Connor, Kirby, Munro, Atkinson, Cutts, Brown and Dearle, 1999), CASPER (Vaughan, Schunke, Koch, Dearle, Marlin and Barter, 1992), Flask (Munro, Connor, Morrison, Scheuerl and Stemple, 1994) and Lumberjack (Hulse, Dearle and Howells, 1999). Here we are interested in identifying basic storage abstractions that are sufficiently simple and generic to avoid encapsulating particular policies to any significant degree. ...
We present a generic API suitable for provision of highly generic storage facilities that can be tailored to produce various individually customised storage infrastructures. The paper identifies a candidate set of minimal storage system building blocks, which are sufficiently simple to avoid encapsulating policy where it cannot be customised by applications, and composable to build highly flexible storage architectures. Four main generic components are defined: the store, the namer, the caster and the interpreter. It is hypothesised that these are sufficiently general that they could act as building blocks for any information storage and retrieval system. The essential characteristics of each are defined by an interface, which may be implemented by multiple implementing classes. Comment: Submitted to ACSC 2004
... Napier88 attempted to explore the limits of orthogonal persistence by incorporating the entire language support environment within a strongly typed persistent store [12,21,[26][27][28][29][30]. The research produced the first integrated, self-contained, type-safe persistent environment. ...
... OOPSLA'08, October 19–23, 2008, Nashville, and database query languages are based on different semantic foundations and optimization strategies [21] . From a programming language viewpoint, databases manage persistent data, which has a lifetime longer than the execution of an individual program [32, 1, 25]. Ideally a unified programming model, transparent persistence, should be applicable to both persistent and non-persistent data. ...
Transparent persistence promises to integrate programming languages and databases by allowing programs to access persistent data with the same ease as non-persistent data. In this work we demonstrate the feasibility of optimizing transparently persistent programs by extracting queries to efficiently prefetch required data. A static analysis derives query structure and conditions across methods that access persistent data. Using the static analysis, our system transforms the program to execute explicit queries. The transformed program composes queries across methods to handle method calls that return persistent data. We extend an existing Java compiler to implement the static analysis and program transformation, handling recursion and parameterized queries. We evaluate the effectiveness of query extraction on the OO7 and TORPEDO benchmarks. This work is focused on programs written in the current version of Java, without languages changes. However, the techniques developed here may also be of value in conjunction with object-oriented languages extended with high-level query syntax.
... Ideally a unified programming model should be applicable to both persistent and non-persistent data. This goal has been pursued for the last 30 years in numerous forms, including orthogonal persistence [2] [3] [4] [25] [30], object-relational mapping [16] [22] [28] [34], and object-oriented databases [12] [15] [27]. Despite differences in particular details, these approaches all share the goal of transparent persistence—a programming paradigm wherein the programmer need not distinguish between persistent and non-persistent values. ...
... Ideally a unified programming model should be applicable to both persistent and non-persistent data. This goal has been pursued for the last 30 years in numerous forms, including orthogonal persistence [2, 3, 4, 25, 30], object-relational mapping [16, 22, 28, 34], and object-oriented databases [12, 15, 27] . Despite differences in particular details, these approaches all share the goal of transparent persistence—a programming paradigm wherein the programmer need not distinguish between persistent and non-persistent values. ...
Transparent persistence promises to integrate programming languages and databases by allowing procedural programs to access persistent data with the same ease as non-persistent data. When the data is stored in a relational database, however, transparent persistence does not naturally leverage the performance benefits of relational query optimization. We present a program analysis that combines the benefits of both approaches by extracting database queries from programs with transparent access to persistent data. The analysis uses a sound abstract interpretation of the original program to approximate the data traversal paths in the program and the conditions under which the paths are used. The resulting paths are then converted into a query, and the program is simplified by removing redundant tests. We study an imperative kernel language with read-only access to persistent data and identify the conditions under which the transformations can be applied. This analysis approach promises to combine the software engineering benefits of transparent data persistence with the performance benefits of database query optimization.
... Object persistence architectures allow programs to create, access, and modify persistent objects, whose lifetime extends beyond the execution of a single program. Examples of object persistence architectures include object-relational mapping tools [10, 6, 28, 24], object-oriented databases [8, 21], and orthogonally persistent programming languages [25, 2, 19, 22]. For example, the Java program inFigure 1 uses Hibernate to print the names of employees, their managers, and the projects they work on. ...
... In particular, any object can be persistent, whether an object is persistent does not affect its other behaviors, and an object is persistent if it is reachable from a persistent root. Orthogonal persistence has been implemented, to a degree, in a variety of programming languages [25, 2, 19, 22]. A key characteristic of orthogonal persistence is that objects are loaded when needed. ...
Object persistence architectures support transparent access to persistent objects. For e-ciency, many of these architectures support queries that can prefetch associated objects as part of the query result. While specifying prefetch manually in a query can signiflcantly improve performance, correct prefetch speciflcations are di-cult to determine and maintain, especially in modular programs. Incorrect prefetching is di-- cult to detect, because prefetch is only an optimization hint. This paper presents AutoFetch, a technique for automatically generating prefetch speciflcations using traversal proflling in object persistence architectures. AutoFetch generates prefetch speciflcations based on previous execu- tions of similar queries. In contrast to previous work, AutoFetch can fetch arbitrary traversal patterns and can execute the optimal number of queries. AutoFetch has been implemented as an extension of Hibernate. We demonstrate that AutoFetch improves performance of traversals in the OO7 benchmark and can automatically predict prefetches that are equivalent to hand-coded queries, while supporting more modular pro- gram designs.
... Los sistemas de programación persistentes de la actualidad se basan ampliamente en los tres principios de ortogonalidad. Estos principios establecen que un sistema posee Persistencia Ortogonal [1] Los sistemas de programación persistentes que cumplen los criterios de ortogonalidad, como por ejemplo Napier [22] o Pjama [21], se basan en su mayor parte en una caché que actúa como intermediaria entre el mecanismo gestor de objetos y el almacenamiento persistente. De esta forma, cuando el programa precisa la utilización de un objeto, el gestor de objetos comprueba primero que no resida ya en la caché, antes de solicitar su traslado desde el almacenamiento persistente, siguiendo una estructura que se puede apreciar en la figura 1. ...
... En la figura se distingue entre Entorno de Programación Persistente y RunTime persistente: esto es así porque algunos sistemas de programación persistente, como Barbados [5] y Napier [22], proveen un entorno de programación integrado, con editor y compilador, mientras otros sólo proveen de un compilador y un entorno de ejecución (Runtime) persistente. El modelo basado en contenedores [14][17], se basa en la división visible del almacenamiento persistente en contenedores para obtener la mayoría de sus ventajas, si bien algunas vienen derivadas de otras características como el compilador de código nativo intel [13]. ...
... Pese a estar considerado como persistente ortogonal, es necesario escribir métodos de almacenamiento y recuperación para aquellos objetos persistentes, lo cual hace que la persistencia no sea en absoluto transparente al usuario. Napier es un sistema de programación persistente bastante antiguo [22], si bien presenta una " inmersión total " en persistencia, de la misma forma que hace Barbados; aunque, como en el caso de Pjama, la forma de trabajo del entorno sea distinta. Aunque no es orientado a objetos y no presenta mecanismos de evolución del esquema, ésto es perfectamente justificable debido a su antigüedad. ...
El término "Persistente" se aplica a los sistemas que proporcionan un mecanismo transparente y automático (en mayor o menor medida) de salvaguarda y recuperación de objetos. El modelo más extendido que implementan estos sistemas es el ortogonal, que sin embargo supone una serie de restricciones de independencia (de los tipos de datos, de código persistente y no persistente ... etc.) muy fuertes. Debido a ello, los sistemas de persistencia ortogonal presentan, en general, un rendimiento bastante pobre. En este artículo, se presenta finalmente el modelo de persistencia basado en contenedores, especialmente en sus tres aspectos más importantes: la gestión de persistencia, la gestión de la evolución del esquema y el rendimiento. A lo largo del artículo, se discutirá cómo el modelo basado en contenedores hace más sencilla la implementación de persistencia en general, así como más eficiente. Si bien el modelo basado en contenedores se presentará en contraposición con el modelo ortogonal, es necesario destacar que el modelo ortogonal es considerado como el marco de trabajo del que el modelo basado en contenedores surge en respuesta a la problemática antes citada.
