On Validity of Program Transformations in the Java Memory Model

Ševčík, Jaroslav; Aspinall, David

doi:10.1007/978-3-540-70592-5_3

Cited by 124 publications

(112 citation statements)

References 11 publications

Supporting

Mentioning

112

Contrasting

Order By: Relevance

“…The C/C++11 concurrency model remains the state of the art for the semantics of a general-purpose shared-memory concurrent programming languages; it is, to the best of our knowledge, sound with respect to the compiler optimisation behaviour of implementations [29] (in contrast to the JMM [16,34]), it is provably compilable to relaxed hardware models [8,7,32], and our work here establishes a machine-checked DRF-SC theorem. But the thin-air problem shows that it allows too many behaviours, and we have seen here that that cannot be solved in a simple per-candidate-execution way, that the problem is not specific to relaxed atomics, that, while an operational solution for those examples is possible, it brings other difficulties, and that there are further problems with undefined behaviour.…”

Section: Resultsmentioning

confidence: 77%

“…This is one of the ways in which the Java Memory Model is unsound with respect to (e.g.) the HotSpot implementation: the implementation does that, but the semantics (unintentionally) disallows it [16,34]. We return to other compiler optimisations in §4 and §6.…”

Section: Sc-violating Compiler Optimisationsmentioning

confidence: 99%

“…For Java, the original language specification [20] was shown by Pugh [31] to be flawed in both directions: too strong to be implementable and too weak for some concurrent programming idioms. A new specification [25] was developed in JSR-133, and incorporated into Java 5.0, but that too has been shown to be unsound with respect to standard compiler optimisations, by Cenciarelli et al [16] and Ševčík and Aspinall [34]. This remains unresolved.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

The Problem of Programming Language Concurrency Semantics

Batty

Memarian

Nienhuis

et al. 2015

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. Despite decades of research, we do not have a satisfactory concurrency semantics for any general-purpose programming language that aims to support concurrent systems code. The Java Memory Model has been shown to be unsound with respect to standard compiler optimisations, while the C/C++11 model is too weak, admitting undesirable thin-air executions.Our goal in this paper is to articulate this major open problem as clearly as is currently possible, showing how it arises from the combination of multiprocessor relaxed-memory behaviour and the desire to accommodate current compiler optimisations. We make several novel contributions that each shed some light on the problem, constraining the possible solutions and identifying new difficulties.First we give a positive result, proving in HOL4 that the existing axiomatic model for C/C++11 guarantees sequentially consistent semantics for simple race-free programs that do not use low-level atomics (DRF-SC, one of the core design goals). We then describe the thin-air problem and show that it cannot be solved, without restricting current compiler optimisations, using any per-candidate-execution condition in the style of the C/C++11 model. Thin-air executions were thought to be confined to programs using relaxed atomics, but we further show that they recur when one attempts to integrate the concurrency model with more of C, mixing atomic and nonatomic accesses, and that also breaks the DRF-SC result. We then describe a semantics based on an explicit operational construction of out-of-order execution, giving the desired behaviour for thin-air examples but exposing further difficulties with accommodating existing compiler optimisations. Finally, we show that there are major difficulties integrating concurrency semantics with the C/C++ notion of undefined behaviour.We hope thereby to stimulate and enable research on this key issue.

show abstract

Section: Resultsmentioning

confidence: 77%

Section: Sc-violating Compiler Optimisationsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

The Problem of Programming Language Concurrency Semantics

Batty

Memarian

Nienhuis

et al. 2015

Programming Languages and Systems

View full text Add to dashboard Cite

show abstract

“…Memory models for Java and C++ guarantee sequential consistency for data-race-free programs [5,18], but semantics are murkier in the presence of races. The Java Memory Model gives racy programs weaker semantics that retain security and safety guarantees, but its complexities have resulted in subtle bugs despite extensive design effort [30]. C++ simply leaves semantics of racy programs undefined.…”

Section: Introductionmentioning

confidence: 99%

Data-race exceptions have benefits beyond the memory model

Wood

Ceze

Grossman

2011

Proceedings of the 2011 ACM SIGPLAN Workshop on Memory Systems Performance and Correctness

View full text Add to dashboard Cite

Proposals to treat data races as exceptions provide simplified semantics for shared-memory multithreaded programming languages and memory models by guaranteeing that execution remains data-race-free and sequentially consistent or an exception is raised. However, the high cost of precise race detection has kept the cost-to-benefit ratio of data-race exceptions too high for widespread adoption. Most research to improve this ratio focuses on lowering performance cost.In this position paper, we argue that with small changes in how we view data races, data-race exceptions enable a broad class of benefits beyond the memory model, including performance and simplicity in applications at the runtime system level. When attempted (but exception-raising) racy accesses are treated as legal -but exceptional -behavior, applications can exploit the guarantees of the data-race exception mechanism by performing potentially racy accesses and guiding execution based on whether these potential races manifest as exceptions. We apply these insights to concurrent garbage collection, optimistic synchronization elision, and best-effort automatic recovery from exceptions due to sequential-consistency-violating races.

show abstract

“…By considering parallel composition of speculations, we also include relaxed memory models [1] into this picture -though not those that try to capture compiler optimizations, that transform the code on the basis of semantical reasoning (see [4,20,24]). …”

Section: Introductionmentioning

confidence: 99%

A Theory of Speculative Computation

Boudol

Petri

2010

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. We propose a formal definition for (valid) speculative computations, which is independent of any implementation technique. By speculative computations we mean optimization mechanisms that rely on relaxing the flow of execution in a given program, and on guessing the values read from pointers in the memory. Our framework for formalizing these computations is the standard operational one that is used to describe the semantics of programming languages. In particular, we introduce speculation contexts, that generalize classical evaluation contexts, and allow us to deal with out of order computations. Regarding concurrent programs, we show that the standard DRF guarantee, asserting that data race free programs are correctly implemented in a relaxed semantics, fails with speculative computations, but that a similar guarantee holds for programs that are free of data races in the speculative semantics.

show abstract

On Validity of Program Transformations in the Java Memory Model

Cited by 124 publications

References 11 publications

The Problem of Programming Language Concurrency Semantics

The Problem of Programming Language Concurrency Semantics

Data-race exceptions have benefits beyond the memory model

A Theory of Speculative Computation

Contact Info

Product

Resources

About