Results 1 - 10
of
35
Multiple Ownership
- In OOPSLA
, 2007
"... Existing ownership type systems require objects to have precisely one primary owner, organizing the heap into an ownership tree. Unfortunately, a tree structure is too restrictive for many programs, and prevents many common design patterns where multiple objects interact. Multiple Ownership is an ow ..."
Abstract
-
Cited by 25 (7 self)
- Add to MetaCart
Existing ownership type systems require objects to have precisely one primary owner, organizing the heap into an ownership tree. Unfortunately, a tree structure is too restrictive for many programs, and prevents many common design patterns where multiple objects interact. Multiple Ownership is an ownership type system where objects can have more than one owner, and the resulting ownership structure forms a DAG. We give a straightforward model for multiple ownership, focusing in particular on how multiple ownership can support a powerful effects system that determines when two computations interfere — in spite of the DAG structure. We present a core programming language MOJO, Multiple Ownership for Java-like Objects, including a type and effects system, and soundness proof. In comparison to other systems, MOJO imposes absolutely no restrictions on pointers, modifications or programs’ structure, but in spite of this, MOJO’s effects can be used to reason about or describe programs ’ behaviour.
Using History Invariants to Verify Observers
, 2007
"... This paper contributes a technique that expands the set of object invariants that one can reason about in modular verification. The technique uses history invariants, two-state invariants that describe the evolution of data values. The technique enables a flexible new way to specify and verify vari ..."
Abstract
-
Cited by 25 (2 self)
- Add to MetaCart
This paper contributes a technique that expands the set of object invariants that one can reason about in modular verification. The technique uses history invariants, two-state invariants that describe the evolution of data values. The technique enables a flexible new way to specify and verify variations of the observer pattern, including iterators. The paper details history invariants and the new kind of object invariants, and proves a soundness theorem.
Formalization of ownership transfer in Universe Types
, 2007
"... Ownership simplifies reasoning about object-oriented programs by controlling aliasing and modifications of objects. Several type systems have been proposed to express and check ownership statically. For ownership systems to be practical, they must allow objects to migrate from one owner to another. ..."
Abstract
-
Cited by 22 (9 self)
- Add to MetaCart
Ownership simplifies reasoning about object-oriented programs by controlling aliasing and modifications of objects. Several type systems have been proposed to express and check ownership statically. For ownership systems to be practical, they must allow objects to migrate from one owner to another. This ownership transfer is common and occurs, for instance, during the initialization of data structures and when data structures are merged. However, existing ownership type systems either do not support ownership transfer at all or they are too restrictive, give rather weak static guarantees, or require a high annotation overhead. In this paper, we present UTT, an extension of Universe Types that supports ownership transfer. UTT combines ownership type checking with a modular static analysis to control references to transferable objects. UTT is very flexible because it permits temporary aliases, even across certain method calls. Nevertheless, it guarantees statically that a cluster of objects is externally-unique when it is transferred and, thus, that ownership transfer is type safe. UTT provides the same encapsulation as Universe Types and requires only negligible annotation overhead.
A unified framework for verification techniques for object invariants
- In FOOL
, 2008
"... Abstract. Object invariants define the consistency of objects. They have subtle semantics, mainly because of call-backs, multi-object invariants, and subclassing. Several verification techniques for object invariants have been proposed. It is difficult to compare these techniques, and to ascertain t ..."
Abstract
-
Cited by 15 (3 self)
- Add to MetaCart
Abstract. Object invariants define the consistency of objects. They have subtle semantics, mainly because of call-backs, multi-object invariants, and subclassing. Several verification techniques for object invariants have been proposed. It is difficult to compare these techniques, and to ascertain their soundness, because of their differences in restrictions on programs and invariants, in the use of advanced type systems (e.g., ownership types), in the meaning of invariants, and in proof obligations. We develop a unified framework for such techniques. We distil seven parameters that characterise a verification technique, and identify sufficient conditions on these parameters which guarantee soundness. We instantiate our framework with three verification techniques from the literature, and use it to assess soundness and compare expressiveness. 1
Ownership, uniqueness and immutability
- In TOOLS
, 2007
"... Programming in an object-oriented language demands a fine balance between high degrees of expressiveness and control. At one level, we need to permit objects to interact freely to achieve our implementation goals. At a higher level, we need to enforce architectural constraints so that the system can ..."
Abstract
-
Cited by 10 (3 self)
- Add to MetaCart
Programming in an object-oriented language demands a fine balance between high degrees of expressiveness and control. At one level, we need to permit objects to interact freely to achieve our implementation goals. At a higher level, we need to enforce architectural constraints so that the system can be understood by new developers and can evolve as requirements change. To resolve this tension, numerous explorers have ventured out into the vast landscape of type systems expressing ownership and behavioural restrictions such as immutability. (Many have never returned.) This work in progress reports on our consolidation of the resulting discoveries into a single programming language. Our language, Joe3, imposes little additional syntactic overhead, yet can encode powerful patterns such as fractional permissions, and the reference modes of Flexible Alias Protection. 1.
Static Inference of Universe Types
- In IWACO
, 2008
"... The Universe type system is an ownership type system which enforces the owners-as-modifiers model. In this paper, we present a static analysis for inference of Universe types. We have implemented the analysis and performed preliminary experiments. Our results are promising. 1. ..."
Abstract
-
Cited by 7 (1 self)
- Add to MetaCart
The Universe type system is an ownership type system which enforces the owners-as-modifiers model. In this paper, we present a static analysis for inference of Universe types. We have implemented the analysis and performed preliminary experiments. Our results are promising. 1.
Universe Types for Topology and Encapsulation
"... The Universe Type System is an ownership type system for object-oriented programming languages that hierarchically structures the object store; it is used to reason modularly about programs. We formalise Universe Types for a core subset of Java in two steps: We first define a Topological Type System ..."
Abstract
-
Cited by 7 (4 self)
- Add to MetaCart
The Universe Type System is an ownership type system for object-oriented programming languages that hierarchically structures the object store; it is used to reason modularly about programs. We formalise Universe Types for a core subset of Java in two steps: We first define a Topological Type System that structures the object store hierarchically into an ownership tree, and demonstrate soundness of the Topological Type System by proving subject reduction. Motivated by concerns of modular verification, we then present an Encapsulation Type System that enforces the owner-as-modifier discipline; that is, that object updates are initiated by the owner of the object. The contributions of this paper are, firstly, an extensive type-theoretic account of the Universe Type System, with explanations and complete proofs, and secondly, the clean separation of the topological from the encapsulation concerns.
Verification of Concurrent Programs with Chalice
, 2009
"... A program verifier is a tool that allows developers to prove that their code satisfies its specification for every possible input and every thread schedule. These lecture notes describe a verifier for concurrent programs called Chalice. Chalice’s verification methodology centers around permissions a ..."
Abstract
-
Cited by 6 (4 self)
- Add to MetaCart
A program verifier is a tool that allows developers to prove that their code satisfies its specification for every possible input and every thread schedule. These lecture notes describe a verifier for concurrent programs called Chalice. Chalice’s verification methodology centers around permissions and permission transfer. In particular, a memory location may be accessed by a thread only if that thread has permission to do so. Proper use of permissions allows Chalice to deduce upper bounds on the set of locations modifiable by a method and guarantees the absence of data races for concurrent programs. The lecture notes informally explain how Chalice works through various examples.
Ownership and Immutability in Generic Java
"... The Java language lacks the important notions of ownership (an object owns its representation to prevent unwanted aliasing) and immutability (the division into mutable, immutable, and readonly data and references). Programmers are prone to design errors such as representation exposure or violation o ..."
Abstract
-
Cited by 6 (4 self)
- Add to MetaCart
The Java language lacks the important notions of ownership (an object owns its representation to prevent unwanted aliasing) and immutability (the division into mutable, immutable, and readonly data and references). Programmers are prone to design errors such as representation exposure or violation of immutability contracts. This paper presents Ownership Immutability Generic Java (OIGJ), a backward-compatible purely-static language extension supporting ownership and immutability. We formally defined a core calculus for OIGJ, based on Featherweight Java, and proved it sound. We also implemented OIGJ and performed case studies on 33,000 lines of code. Creation of immutable cyclic structures requires a “cooking phase ” in which the structure is mutated but the outside world cannot observe this mutation. OIGJ uses ownership information to facilitate creation of immutable cyclic structures, by safely prolonging the cooking phase even after the constructor finishes. OIGJ is easy for a programmer to use, and it is easy to implement (flow-insensitive, using only 14 rules). Yet, OIGJ is more expressive than previous ownership languages, in the sense that it can type-check more good code. OIGJ can express the factory and visitor patterns, and OIGJ can type-check Sun’s java.util collections (except for the clone method) without refactoring and with only a small number of annotations. Previous work required major refactoring of existing code in order to fit its ownership restrictions. Forcing refactoring of well-designed code is undesirable because it costs programmer effort, degrades the design, and hinders adoption in the mainstream community.
Implicit Ownership Types for Memory Management
"... Abstract. The Real-time Specification for Java (RTSJ) introduced a range of language features for explicit memory management. While the RTSJ gives programmers fine control over memory use and allows linear allocation and constant time deallocation, the RTSJ relies upon dynamic runtime checks for saf ..."
Abstract
-
Cited by 5 (3 self)
- Add to MetaCart
Abstract. The Real-time Specification for Java (RTSJ) introduced a range of language features for explicit memory management. While the RTSJ gives programmers fine control over memory use and allows linear allocation and constant time deallocation, the RTSJ relies upon dynamic runtime checks for safety making it unsuitable for safety critical applications. We introduce ScopeJ, a statically typed, multi-threaded, object calculus in which scopes are first class constructs. Scopes reify allocation contexts and provide a safe alternative to automatic memory management. Safety is the result of our use of an ownership type system that enforces a topology on run-time patterns of references. ScopeJ’s type system is novel in that ownership annotations are implicit. This substantially reduces the burden for developers, thus increasing the likelihood of adoption. The notion of implicit ownership is particularly appealing when combined with pluggable type systems, as one can apply different type constraints to components depending on the requirements. In related work we have demonstrated the usefulness of our approach in different applications. 1

