OwnKit: Inferring Modularly Checkable Ownership Annotations for Java

Dymnikov, Constantine; Pearce, David J.; Potanin, Alex

doi:10.1109/aswec.2013.30

Cited by 7 publications

(2 citation statements)

References 41 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…7.2.2 Ownership. Ownership types and related systems attempt-in a similar fashion to Balloons-to provide strong guarantees about when and where aliasing is permitted between objects [2,21,29,35,37,44,62,82,85,98,99,101,106,118,136]. They have found use in areas such as: parallel and concurrent systems [21,22], specification languages [13,94], real-time systems [5,107], and more.…”

Section: Balloonsmentioning

confidence: 99%

A Lightweight Formalism for Reference Lifetimes and Borrowing in Rust

Pearce

2021

ACM Trans. Program. Lang. Syst.

Self Cite

View full text Add to dashboard Cite

Rust is a relatively new programming language that has gained significant traction since its v1.0 release in 2015. Rust aims to be a systems language that competes with C/C++. A claimed advantage of Rust is a strong focus on memory safety without garbage collection. This is primarily achieved through two concepts, namely, reference lifetimes and borrowing . Both of these are well-known ideas stemming from the literature on region-based memory management and linearity / uniqueness . Rust brings both of these ideas together to form a coherent programming model. Furthermore, Rust has a strong focus on stack-allocated data and, like C/C++ but unlike Java, permits references to local variables. Type checking in Rust can be viewed as a two-phase process: First, a traditional type checker operates in a flow-insensitive fashion; second, a borrow checker enforces an ownership invariant using a flow-sensitive analysis. In this article, we present a lightweight formalism that captures these two phases using a flow-sensitive type system that enforces “ type and borrow safety .” In particular, programs that are type and borrow safe will not attempt to dereference dangling pointers. Our calculus core captures many aspects of Rust, including copy- and move-semantics, mutable borrowing, reborrowing, partial moves, and lifetimes. In particular, it remains sufficiently lightweight to be easily digested and understood and, we argue, still captures the salient aspects of reference lifetimes and borrowing. Furthermore, extensions to the core can easily add more complex features (e.g., control-flow, tuples, method invocation). We provide a soundness proof to verify our key claims of the calculus. We also provide a reference implementation in Java with which we have model checked our calculus using over 500B input programs. We have also fuzz tested the Rust compiler using our calculus against 2B programs and, to date, found one confirmed compiler bug and several other possible issues.

show abstract

Section: Balloonsmentioning

confidence: 99%

A Lightweight Formalism for Reference Lifetimes and Borrowing in Rust

Pearce

2021

ACM Trans. Program. Lang. Syst.

Self Cite

View full text Add to dashboard Cite

show abstract

“…As a result, much work has focused on inferring properties that can be viewed either as limited contracts or extended type systems. For example, researchers have developed tools that infer non-null annotations [Ekman and Hedin 2007] (in a world without Non-Null by Default) and ownership annotations [Dymnikov et al 2013;Flanagan and Freund 2007;Milanova and Liu 2009].…”

Section: Detecting Contractsmentioning

confidence: 99%

Putting the Semantics into Semantic Versioning

Lam¹,

Dietrich²,

Pearce³

2020

Preprint

Self Cite

View full text Add to dashboard Cite

The long-standing aspiration for software reuse has made astonishing strides in the past few years. Many modern software development ecosystems now come with rich sets of publicly-available components contributed by the community. Downstream developers can leverage these upstream components, boosting their productivity.However, components evolve at their own pace. This imposes obligations on and yields benefits for downstream developers, especially since changes can be breaking, requiring additional downstream work to adapt to. Upgrading too late leaves downstream vulnerable to security issues and missing out on useful improvements; upgrading too early results in excess work. Semantic versioning has been proposed as an elegant mechanism to communicate levels of compatibility, enabling downstream developers to automate dependency upgrades.While it is questionable whether a version number can adequately characterize version compatibility in general, we argue that developers would greatly benefit from tools such as semantic version calculators to help them upgrade safely. The time is now for the research community to develop such tools: large component ecosystems exist and are accessible, component interactions have become observable through automated builds, and recent advances in program analysis make the development of relevant tools feasible. In particular, contracts (both traditional and lightweight) are a promising input to semantic versioning calculators, which can suggest whether an upgrade is likely to be safe.

show abstract