Results 1 - 10
of
181
Ownership Types for Flexible Alias Protection
- In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA
, 1998
"... Object-oriented programming languages allow inter-object aliasing. Although necessary to construct linked data structures and networks of interacting objects, aliasing is problematic in that an aggregate object's state can change via an alias to one of its components, without the aggregate being awa ..."
Abstract
-
Cited by 278 (27 self)
- Add to MetaCart
Object-oriented programming languages allow inter-object aliasing. Although necessary to construct linked data structures and networks of interacting objects, aliasing is problematic in that an aggregate object's state can change via an alias to one of its components, without the aggregate being aware of any aliasing. Ownership types form a static type system that indicates object ownership. This provides a flexible mechanism to limit the visibility of object references and restrict access paths to objects, thus controlling a system's dynamic topology. The type system is shown to be sound, and the specific aliasing properties that a system's object graph satisfies are formulated and proven invariant for well-typed programs. Keywords Alias protection, sharing, containment, ownership, representation exposure, programming language design 1
Type-based race detection for Java
- IN PROCEEDINGS OF THE SIGPLAN CONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION
"... This paper presents a static race detection analysis for multithreaded Java programs. Our analysis is based on a formal type system that is capable of capturing many common synchronization patterns. These patterns include classes with internal synchronization, classes that require client-side synchr ..."
Abstract
-
Cited by 221 (22 self)
- Add to MetaCart
This paper presents a static race detection analysis for multithreaded Java programs. Our analysis is based on a formal type system that is capable of capturing many common synchronization patterns. These patterns include classes with internal synchronization, classes that require client-side synchronization, and thread-local classes. Experience checking over 40,000 lines of Java code with the type system demonstrates that it is an effective approach for eliminating races conditions. On large examples, fewer than 20 additional type annotations per 1000 lines of code were required by the type checker, and we found a number of races in the standard Java libraries and other test programs. 1
Typed Memory Management in a Calculus of Capabilities
, 2000
"... Region-based memory management is an alternative to standard tracing garbage collection that makes potentially dangerous operations such as memory deallocation explicit but verifiably safe. In this article, we present a new compiler intermediate language, called the Capability Calculus, that supp ..."
Abstract
-
Cited by 186 (23 self)
- Add to MetaCart
Region-based memory management is an alternative to standard tracing garbage collection that makes potentially dangerous operations such as memory deallocation explicit but verifiably safe. In this article, we present a new compiler intermediate language, called the Capability Calculus, that supports region-based memory management and enjoys a provably safe type system. Unlike previous region-based type systems, region lifetimes need not be lexically scoped and yet the language may be checked for safety without complex analyses. Therefore, our type system may be deployed in settings such as extensible operating systems where both the performance and safety of untrusted code is important.
Region-Based Memory Management in Cyclone
- IN PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION (PLDI'02)
, 2002
"... Cyclone is a type-safe programming language derived from C. The primary design goal of Cyclone is to let programmers control data representation and memory management without sacrificing type-safety. In this paper, we focus on the region-based memory management of Cyclone and its static typing disci ..."
Abstract
-
Cited by 163 (13 self)
- Add to MetaCart
Cyclone is a type-safe programming language derived from C. The primary design goal of Cyclone is to let programmers control data representation and memory management without sacrificing type-safety. In this paper, we focus on the region-based memory management of Cyclone and its static typing discipline. The design incorporates several advancements, including support for region subtyping and a coherent integration with stack allocation and a garbage collector. To support separate compilation, Cyclone requires programmers to write some explicit region annotations, but a combination of default annotations, local type inference, and a novel treatment of region e#ects reduces this burden. As a result, we integrate C idioms in a region-based framework. In our experience, porting legacy C to Cyclone has required altering about 8% of the code; of the changes, only 6% (of the 8%) were region annotations.
Alias Types
- In European Symposium on Programming
, 1999
"... Linear type systems allow destructive operations such as object deallocation and imperative updates of functional data structures. These operations and others, such as the ability to reuse memory at di#erent types, are essential in low-level typed languages. However, traditional linear type syste ..."
Abstract
-
Cited by 157 (24 self)
- Add to MetaCart
Linear type systems allow destructive operations such as object deallocation and imperative updates of functional data structures. These operations and others, such as the ability to reuse memory at di#erent types, are essential in low-level typed languages. However, traditional linear type systems are too restrictive for use in low-level code where it is necessary to exploit pointer aliasing. We present a new typed language that allows functions to specify the shape of the store that they expect and to track the flow of pointers through a computation. Our type system is expressive enough to represent pointer aliasing and yet safely permit destructive operations.
Ownership Types for Object Encapsulation
- In Principles of Programming Languages (POPL
, 2003
"... object encapsulation and enable local reasoning about program correctness in object-oriented languages. However, a type system that enforces strict object encapsulation is too constraining: it does not allow e#cient implementation of important constructs like iterators. This paper argues that the ri ..."
Abstract
-
Cited by 125 (8 self)
- Add to MetaCart
object encapsulation and enable local reasoning about program correctness in object-oriented languages. However, a type system that enforces strict object encapsulation is too constraining: it does not allow e#cient implementation of important constructs like iterators. This paper argues that the right way to solve the problem is to allow objects of classes defined in the same module to have privileged access to each other's representations; we show how to do this for inner classes. This approach allows programmers to express constructs like iterators and yet supports local reasoning about the correctness of the classes, because a class and its inner classes together can be reasoned about as a module. The paper also sketches how we use our variant of ownership types to enable e#cient software upgrades in persistent object stores.
Memory Management with Explicit Regions
, 1998
"... Much research has been devoted to studies of and algorithms for memory management based on garbage collection or explicit allocation and deallocation. An alternative approach, region-based memory management, has been known for decades, but has not been wellstudied. In a region-based system each allo ..."
Abstract
-
Cited by 115 (4 self)
- Add to MetaCart
Much research has been devoted to studies of and algorithms for memory management based on garbage collection or explicit allocation and deallocation. An alternative approach, region-based memory management, has been known for decades, but has not been wellstudied. In a region-based system each allocation specifies a region, and memory is reclaimed by destroying a region, freeing all the storage allocated therein. We show that on a suite of allocation-intensive C programs, regions are competitive with malloc/free and sometimes substantially faster. We also show that regions support safe memory management with low overhead. Experience with our benchmarks suggests that modifying many existing programs to use regions is not difficult. 1 Introduction The two most popular memory management techniques are explicit allocation and deallocation, as in C's malloc/free, and various forms of garbagecollection [Wil92]. Both have well-known advantages and disadvantages, discussed further below. A t...
Static Prediction of Heap Space Usage for First-order Functional Programs
- in Symposium on Principles of Programming Languages (POPL’03
, 2003
"... Categories and Subject Descriptors We show how to efficiently obtain linear a priori bounds on the heap space consumption of first-order functional programs. The analysis takes space reuse by explicit deallocation into account and also furnishes an upper bound on the heap usage in the presence of ga ..."
Abstract
-
Cited by 112 (22 self)
- Add to MetaCart
Categories and Subject Descriptors We show how to efficiently obtain linear a priori bounds on the heap space consumption of first-order functional programs. The analysis takes space reuse by explicit deallocation into account and also furnishes an upper bound on the heap usage in the presence of garbage collection. It covers a wide variety of examples including, for instance, the familiar sorting algorithms for lists, including quicksort. The analysis relies on a type system with resource annotations. Linear programming (LP) is used to automatically infer derivations in this enriched type system. We also show that integral solutions to the linear programs derived correspond to programs that can be evaluated without any operating system support for memory management. The particular integer linear programs arising in this way are shown to be feasibly solvable under mild assumptions.
Object Ownership and Containment
, 2001
"... Object-oriented programming relies on inter-object aliases to implement data structures and other abstractions. Objects have mutable state, but it is when mutable state interacts with aliasing that problems arise. Through aliasing an object's state can be changed without the object being aware of t ..."
Abstract
-
Cited by 112 (17 self)
- Add to MetaCart
Object-oriented programming relies on inter-object aliases to implement data structures and other abstractions. Objects have mutable state, but it is when mutable state interacts with aliasing that problems arise. Through aliasing an object's state can be changed without the object being aware of the changes, potentially violating the object's invariants. This problem is fundamentally unresolvable. Many idioms such as the Observer design pattern rely on it. Hence aliasing cannot be eliminated from object-oriented programming, it can only be managed. Various proposals have appeared in the literature addressing the issue of alias management. The most promising are based on alias encapsulation, which limits access to objects to within certain well-defined boundaries. Our approach called ownership types falls into this category. An object can specify the objects it owns, called its representation, and which objects can access its representation. A type system protects the representation by enforcing a well-defined containment invariant. Our approach is a formal one. Ownership types are cast as a type system using an minor extension to Abadi and Cardelli's object calculus with subtyping. With this formalisation we prove the soundness of our ownership types system and demonstrate that well-typed programs satisfy the containment invariant. In addition, we also provide a firm grounding to enable ownership types to be safely added to an objectoriented programming language with inheritance, subtyping, and nested classes, as well as offering a sound basis for future work. Our type system can model aggregate objects with multiple interface objects sharing representation and friendly functions which access multiple objects' private representations, among other examples, thus over...

