Results 1 - 10
of
114
Ownership Types for Safe Programming: Preventing Data Races and Deadlocks
, 2002
"... This paper presents a new static type system for multi-threaded programs; well-typed programs in our system are guaranteed to be free of data races and deadlocks. Our type system allows programmers to partition the locks into a fixed number of equivalence classes and specify a partial order among th ..."
Abstract
-
Cited by 261 (13 self)
- Add to MetaCart
This paper presents a new static type system for multi-threaded programs; well-typed programs in our system are guaranteed to be free of data races and deadlocks. Our type system allows programmers to partition the locks into a fixed number of equivalence classes and specify a partial order among the equivalence classes. The type checker then statically verifies that whenever a thread holds more than one lock, the thread acquires the locks in the descending order. Our system also allows...
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.
Ownership, Encapsulation and the Disjointness of Type and Effect
- In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA
, 2002
"... Ownership types provide a statically enforceable notion of object-level encapsulation. We extend ownership types with computational e#ects to support reasoning about objectoriented programs. The ensuing system provides both access control and e#ects reporting. Based on this type system, we codify tw ..."
Abstract
-
Cited by 108 (8 self)
- Add to MetaCart
Ownership types provide a statically enforceable notion of object-level encapsulation. We extend ownership types with computational e#ects to support reasoning about objectoriented programs. The ensuing system provides both access control and e#ects reporting. Based on this type system, we codify two formal systems for reasoning about aliasing and the disjointness of computational e#ects. The first can be used to prove that evaluation of two expressions will never lead to aliases, while the latter can be used to show the non-interference of two expressions.
Ownership Domains: Separating Aliasing Policy from Mechanism
, 2004
"... Ownership types promise to provide a practical mechanism for enforcing stronger encapsulation by controlling aliasing in objectoriented languages. However, previous ownership type proposals have tied the aliasing policy of a system to the mechanism of ownership. As a result, these proposals are too ..."
Abstract
-
Cited by 100 (13 self)
- Add to MetaCart
Ownership types promise to provide a practical mechanism for enforcing stronger encapsulation by controlling aliasing in objectoriented languages. However, previous ownership type proposals have tied the aliasing policy of a system to the mechanism of ownership. As a result, these proposals are too weak to express many important aliasing constraints, yet also so restrictive that they prohibit many useful programming idioms. In this paper, we propose ownership domains, which decouple encapsulation policy from the mechanism of ownership in two key ways. First, developers can specify multiple ownership domains for each object, permitting a fine-grained control of aliasing compared to systems that provide only one ownership domain for each object. Second, developers can specify the permitted aliasing between each pair of domains in the system, providing more flexibility compared to systems that enforce a fixed policy for inter-domain aliasing. Because it decouples policy from mechanism, our alias control system is both more precise and more flexible than previous ownership type systems.
Encapsulating Objects with Confined Types
- In OOPSLA
, 2001
"... Object-oriented languages provide little support for encapsulating objects. Reference semantics allows objects to escape their defining scope. The pervasive aliasing that ensues remains a major source of software defects. This paper introduces Kacheck/J a tool for inferring object encapsulation prop ..."
Abstract
-
Cited by 87 (6 self)
- Add to MetaCart
Object-oriented languages provide little support for encapsulating objects. Reference semantics allows objects to escape their defining scope. The pervasive aliasing that ensues remains a major source of software defects. This paper introduces Kacheck/J a tool for inferring object encapsulation properties in large Java programs. Our goal is to develop practical tools to assist software engineers, thus we focus on simple and scalable techniques. Kacheck/J is able to infer confinement for Java classes. A class and its subclasses are confined if all of their instances are encapsulated in their defining package. This simple property can be used to identify accidental leaks of sensitive objects. The analysis is scalable and efficient; Kacheck/J is able to infer confinement on a corpus of 46,000 classes (115 MB) in 6 minutes. 1.
Ownership Types for Safe Region-Based Memory Management in Real-Time Java
- IN PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION (PLDI
, 2003
"... The Real-Time Specification for Java (RTSJ) allows a program to create real-time threads with hard real-time constraints. Real-time threads use region-based memory management to avoid unbounded pauses caused by interference from the garbage collector. The RTSJ uses runtime checks to ensure that dele ..."
Abstract
-
Cited by 84 (8 self)
- Add to MetaCart
The Real-Time Specification for Java (RTSJ) allows a program to create real-time threads with hard real-time constraints. Real-time threads use region-based memory management to avoid unbounded pauses caused by interference from the garbage collector. The RTSJ uses runtime checks to ensure that deleting a region does not create dangling references and that real-time threads do not access references to objects allocated in the garbage-collected heap. This paper presents a static type system that guarantees that these runtime checks will never fail for well-typed programs. Our type system therefore 1) provides an important safety guarantee for real-time programs and 2) makes it possible to eliminate the runtime checks and their associated overhead. Our system also makes several contributions over previous work on region types. For object-oriented programs, it combines the benefits of region types and ownership types in a unified type system framework. For multithreaded programs, it allows long-lived threads to share objects without using the heap and without memory leaks. For real-time programs, it ensures that real-time threads do not interfere with the garbage collector. Our experience indicates that our type system is suciently expressive and requires little programming overhead, and that eliminating the RTSJ runtime checks using a static type system can significantly decrease the execution time of real-time programs.
External uniqueness is unique enough
- In European Conference for Object-Oriented Programming (ECOOP
, 2003
"... Abstract. External uniqueness is a surprising new way to add unique references to an OOPL. The idea is that an externally unique reference is the only reference into an aggregate from outside the aggregate. Internal references which do not escape the boundary of the aggregate are innocuous and there ..."
Abstract
-
Cited by 79 (14 self)
- Add to MetaCart
Abstract. External uniqueness is a surprising new way to add unique references to an OOPL. The idea is that an externally unique reference is the only reference into an aggregate from outside the aggregate. Internal references which do not escape the boundary of the aggregate are innocuous and therefore permitted. Based on ownership types, our proposal not only overcomes an abstraction problem from which existing uniqueness proposals suffer, it also enables many examples which are inherently not unique, such as a unique reference to a set of links in a doubly-linked list, without losing the benefits of uniqueness. 1
A Practical Flow-Sensitive and Context-Sensitive C and C++ Memory Leak Detector
, 2003
"... This paper presents a static analysis tool that can automatically find memory leaks and deletions of dangling pointers in large C and C++ applications. ..."
Abstract
-
Cited by 72 (4 self)
- Add to MetaCart
This paper presents a static analysis tool that can automatically find memory leaks and deletions of dangling pointers in large C and C++ applications.
Modular invariants for layered object structures
- Science of Computer Programming
"... Classical specification and verification techniques support invariants for individual objects whose fields are primitive values, but do not allow sound modular reasoning about invariants involving more complex object structures. Such non-trivial object structures are common, and occur in lists, hash ..."
Abstract
-
Cited by 66 (30 self)
- Add to MetaCart
Classical specification and verification techniques support invariants for individual objects whose fields are primitive values, but do not allow sound modular reasoning about invariants involving more complex object structures. Such non-trivial object structures are common, and occur in lists, hash tables, and whenever systems are built in layers. A sound and modular verification technique for layered object structures has to deal with the well-known problem of representation exposure and the problem that invariants of higher layers are potentially violated by methods in lower layers; such methods cannot be modularly shown to preserve these invariants. We generalize classical techniques to cover layered object structures using a refined semantics for invariants based on an ownership model for alias control. This semantics enables sound and modular reasoning. We further extend this ownership technique to even more expressive invariants that gain their modularity by imposing certain visibility requirements.

