We present an approach to searching genetic DNA sequences using an adaptation of the suffix tree data structure deployed on the general purpose persistent Java platform, PJama. Our implementation technique is novel, in that it allows us to build suffix trees on disk for arbitrarily large sequences, for instance for the longest human chromosome consisting of 263 million letters. We propose to use such indexes as an alternative to the current practice of serial scanning. We describe our tree creation algorithm, analyse the performance of our index, and discuss the interplay of the data structure with object store architectures. Early measurements are presented.

There is a class of important computer applications that must run without interruption and yet must be changed from time to time to fix bugs or upgrade functionality. In this paper, we present the initial runtime evolution framework which we have developed for the HotSpot Java Virtual Machine, that allows us to change running applications on-the-fly, without interruption. We describe our staged implementation plan, where stages correspond to increasing levels of implementation complexity, yet on each stage a reasonably complete set of facilities is provided. The first stage — support for changes to method bodies only — has already been implemented and is to be included in the forthcoming Java 2 Platform release. We discuss multiple policies for dealing with active methods of running applications, present our thoughts on instance conversion implementation, and suggest that runtime evolution technology can be used for dynamic fine-grain profiling of applications. 1

Our aim is to develop new database technologies for the approximate matching of unstructured string data using indexes. We explore the potential of the suffix tree data structure in this context. We present a new method of building suffix trees, allowing us to build trees in excess of RAM size, which has hitherto not been possible. We show that this method performs in practice as well as the O(n) method of Ukkonen [70]. Using this method we build indexes for 200Mb of protein and 300Mbp of DNA, whose disk-image exceeds the available RAM. We show experimentally that suffix trees can be effectively used in approximate string matching with biological data. For a range of query lengths and error bounds the suffix tree reduces the size of the unoptimised O(mn) dynamic programming calculation required in the evaluation of string similarity, and the gain from indexing increases with index size. In the indexes we built this reduction is significant, and less than 0.3% of the expected matrix is evaluated. We detail the requirements for further database and algorithmic research to support efficient use of large suffix indexes in biological applications.

PJama 1 is the latest version of an orthogonally persistent platform for Java. It depends on a new persistent object store, Sphere, and provides facilities for class evolution. This evolution technology supports an arbitrary set of changes to the classes, which may have arbitrarily large populations of persistent objects. We verify that the changes are safe. When there are format changes, we also convert all of the instances, while leaving their identities unchanged. We aspire to both very large persistent object stores and freedom for developers to specify arbitrary conversion methods in Java to convey information from old to new formats. Evolution operations must be safe and the evolution cost should be approximately linear in the number of objects that must be reformatted. In order that these conversion methods can be written easily, we continue to present the pre-evolution state consistently to Java executions throughout an evolution. At the completion of applying all of these tra...

Abstract. A transaction defines a locus of computation that satisfies important concurrency and failure properties. These so-called ACID properties provide strong serialization guarantees that allow us to reason about concurrent and distributed programs in terms of higher-level units of computation (e.g., transactions) rather than lower-level data structures (e.g., mutual-exclusion locks). This paper presents a framework for specifying the semantics of a transactional facility integrated within a host programming language. The TFJ calculus, an object calculus derived from Featherweight Java, supports nested and multi-threaded transactions. We give a semantics to TFJ that is parameterized by the definition of the transactional mechanism that permits the study of different transaction models. We give two instantiations: one that defines transactions in terms of a versioning-based optimistic concurrency model, and the other which specifies transactions in terms of a pessimistic two-phase locking protocol, and present soundness and serializability properties for our semantics. 1

Orthogonal persistence provides the programmer with persistence for all data types, with minimal impact on the programing model or development process. We motivate the addition of orthogonal persistence to the Java ™ platform, and show how this results in a simple and appealing application development model. The overall goal is to provide the illusion of continuous computation in the face of system shutdowns, planned or unplanned. This is achieved by checkpointing the state of the system periodically to stable memory. We describe how the principles of orthogonal persistence are applied to the Java ™ programming language and specify the small set of changes to the Java language specification and core libraries necessary to fulfill these principles. We describe the rationale for our particular choices, informed by the experience with the PJama prototype implementations. Finally, the programming model for managing state that is external to the Java ™ virtual machine is discussed in detail.

Access to persistent data is a requirement for the majority of computer applications. The Java programming language and associated run-time environment provide excellent features for the construction of reliable and robust applications, but currently these do not extend to the domain of persistent data. Many mechanisms for managing persistent data have been proposed, some of which are now included in the standard Java platforms, e.g., J2SE ™ and J2EE™. This paper defines a set of criteria by which persistence mechanisms may be compared and then applies the criteria to a representative set of widely used mechanisms. The criteria are evaluated in the context of a widely-known benchmark, which was ported to each of the mechanisms, and include performance and scalability results.

Palm organizers are widely used in a multi-tasking fashion. Users switch from one application to another without losing the context established in either of them. Despite its obvious usefulness, there is no automatic support for this convenience in the organizer’s operating system, PalmOS. Programmers must implement event callbacks that have to operate on a PalmOS database API to save and reload specific application state. In this report, we describe how this burden can be eliminated. We enhanced the Spotless Java ™ virtual machine for the Palm organizer with transparent multi-tasking support that automates persistence. As a consequence, running Java programs can be beamed between the infra-red links of two Palm organizers. A beamed program will resume on the receiving organizer in the exact same state as on the sending device. A HotSync operation effectively establishes a checkpoint for each involved Java program. The original Spotless JVM’s address range for running programs is limited to a few tens of KB in the dynamic RAM area. By directly addressing the much larger static RAM area, our modified VM supports address ranges of several MB. We provide an easy-to-use protocol that leverages persistent threads for automatic life cycle control of external resources (e.g., windows, forms and databases). When applied at the library level, this protocol maintains complete persistence transparency for the application programmer.

Abstract—With the wide support for serialization in objectoriented programming languages, persistent objects have become common place. Retrieving previously “persisted ” objects from classes whose schema changed is however difficult, and may lead to invalidating the consistency of the application. The ESCHER framework addresses this issues through an IDE-based approach that handles schema evolution by managing versions of the code and generating transformation functions automatically. The infrastructure also enforces class invariants to prevent the introduction of any corrupt objects. This article describes the principles behind invariant-safe schema evolution, and the design and implementation of the ESCHER system. Index Terms—versioning; refactoring; persistence; serialization; object-oriented schema evolution; IDE integration I.

Abstract—With the wide support for object serialization in object-oriented programming languages, persistent objects have become common place and most large object-oriented software systems rely on extensive amounts of persistent data. Such systems also evolve over time. Retrieving previously persisted objects from classes whose schema has changed is however difficult, and may lead to invalidating the consistency of the application. The ESCHER framework addresses these issues through an IDE-integrated approach that handles class schema evolution by managing versions of the code and generating transformation functions automatically. The infrastructure also enforces class invariants to prevent the introduction of potentially corrupt objects. This article describes a model for class attribute changes, a measure for class evolution robustness, four empirical studies, and the design and implementation of the ESCHER system. Index Terms—versioning; persistence; serialization; object-oriented class schema evolution; IDE integration