Results 1 - 10
of
12
Local Verification of Global Invariants in Concurrent Programs
, 2010
"... We describe a practical method for reasoning about realistic concurrent programs. Our method allows global two-state invariants that restrict update of shared state. We provide simple, sufficient conditions for checking those global invariants modularly. The method has been implemented in VCC 3, an ..."
Abstract
-
Cited by 31 (5 self)
- Add to MetaCart
(Show Context)
We describe a practical method for reasoning about realistic concurrent programs. Our method allows global two-state invariants that restrict update of shared state. We provide simple, sufficient conditions for checking those global invariants modularly. The method has been implemented in VCC 3, an automatic, sound, modular verifier for concurrent C programs. VCC has been used to verify functional correctness of tens of thousands of lines of Microsoft’s Hyper-V virtualization platform 4 and of SYSGO’s embedded real-time operating system PikeOS.
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 15 (9 self)
- Add to MetaCart
(Show Context)
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.
Type-based object immutability with flexible initialization
, 2009
"... The following full text is an author's version which may differ from the publisher's version. For additional information about this publication click this link. ..."
Abstract
-
Cited by 12 (0 self)
- Add to MetaCart
(Show Context)
The following full text is an author's version which may differ from the publisher's version. For additional information about this publication click this link.
Using the Spec# Language, Methodology, and Tools to Write Bug-Free Programs
, 2009
"... Spec# is a programming system for the development of correct programs. It consists of a programming language, a verification methodology, and tools. The Spec # language extends C# with contracts, which allow programmers to document their design decisions in the code. The verification methodology pro ..."
Abstract
-
Cited by 11 (4 self)
- Add to MetaCart
Spec# is a programming system for the development of correct programs. It consists of a programming language, a verification methodology, and tools. The Spec # language extends C# with contracts, which allow programmers to document their design decisions in the code. The verification methodology provides rules and guidelines for how to use the Spec# features to express and check properties of interesting implementations. Finally, the tool support consists of a compiler that emits run-time checks for many contracts and a static program verifier that attempts to prove automatically that an implementation satisfies its specification. These lecture notes teach the use of the Spec# system, focusing on specification and static verification.
Featherweight Ownership and Immutability Generic Java (FOIGJ
, 2010
"... This technical report contains proofs that were omitted from our paper entitled “Ownership and Immutability in Generic Java”. Please read the paper first, and only then proceed to reading this technical report, because this technical report is not self contained. We only include a summary of the syn ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
(Show Context)
This technical report contains proofs that were omitted from our paper entitled “Ownership and Immutability in Generic Java”. Please read the paper first, and only then proceed to reading this technical report, because this technical report is not self contained. We only include a summary of the syntax (Fig. 1), subtyping rules (Fig. 2), expression typing rules (Fig. 3), and reduction rules (Fig. 4).
Immutability
, 2013
"... One of the main reasons aliasing has to be controlled, as highlighted in another chapter [1] of this book [2], is the possibility that a variable can unexpectedly change its value without the referrer’s knowledge. This book will not be complete without a discussion of the impact of immutability on ..."
Abstract
- Add to MetaCart
(Show Context)
One of the main reasons aliasing has to be controlled, as highlighted in another chapter [1] of this book [2], is the possibility that a variable can unexpectedly change its value without the referrer’s knowledge. This book will not be complete without a discussion of the impact of immutability on reference-abundant imperative object-oriented languages. In this chapter we briefly survey possible definitions of immutability and present recent work by the authors on adding immutability to object-oriented languages and how it impacts aliasing.
Ownership, Filters and Crossing Handlers Ownership, Filters and Crossing Handlers Flexible Ownership in Dynamic Languages
"... scg.unibe.ch Sharing mutable objects can result in broken invariants, exposure of internal details, and other subtle bugs. To prevent such issues, it is important to control accessibility and aliasing of objects. Dynamic Ownership is an effective way to do so, but its owner-as-dominator discipline i ..."
Abstract
- Add to MetaCart
(Show Context)
scg.unibe.ch Sharing mutable objects can result in broken invariants, exposure of internal details, and other subtle bugs. To prevent such issues, it is important to control accessibility and aliasing of objects. Dynamic Ownership is an effective way to do so, but its owner-as-dominator discipline is too restrictive: objects are either accessible or not. We propose in this paper to control accessibility and aliasing with more flexibility using two mechanisms, filters and crossing handlers. We demonstrate the benefits of the flexibility offered by these mechanisms, and report on the adaptation of a Smalltalk web server with our approach. We conclude that our variant of dynamic ownership is flexible enough to accommodate an existing design, while at the same time constraining it enough to highlight design anomalies.
Changing Hashcodes: Objects, Intialisation, and Collections
, 2009
"... Java requires objects’ hashcodes to be consistent with object equality, and to change only when an object’s equality changes. Equality dependent Java collections impose a stricter contextual contract on an objects ’ equality, comparability, and hashcode methods: that they cannot change while those o ..."
Abstract
- Add to MetaCart
(Show Context)
Java requires objects’ hashcodes to be consistent with object equality, and to change only when an object’s equality changes. Equality dependent Java collections impose a stricter contextual contract on an objects ’ equality, comparability, and hashcode methods: that they cannot change while those objects are in collections. By dynamically profiling 30 Java applications, we have determined that programmers use quite sophisticated techniques to ensure their objects meet these contracts. Some objects are immutable; some objects are initially mutable, but become immutable when inserted into equality- dependent collections; some objects continue to change when inserted into equality dependent collections — but those changes do not affect equality or hashcodes. On the other hand, some objects inserted into collections that do not depend on object equality, hashcodes, or comparisons will contine to change all their state, including equality and hashcode, while they are in those collections. Programmers and educators can use these results to ensure they (or their students) are aware of these subtle conditional contracts underlying Java’s collection design. These results can also guide language designers adding support for collections, relations, or equality: in particular; while immutablility suffices for many cases, it does not cover all of them.
