JmmSolve: A Generative Java Memory Model Implemented in Prolog and CHR

Abstract

The memory model of a programming language specifies the interaction between multiple threads and main memory. Basically, the model says for every value obtained by a read operation in a program by what write operation it has been produced. In a multi-threaded unsynchronized program this need not be a deterministic linking from reads to writes. For a multi-platform language such as Java, a memory model is essential to guarantee portability of programs. However, several undesirable properties of the current Java Memory Model (JMM) have been revealed: it is not an easy model to understand by programmers, gives rise to some unwanted behavior and is hard to implement on current hardware architectures. Because of this, Java Specification Request 133 [2] has called for a new JMM that fixes the current problems. The Concurrent Constraint-based Memory Machines (CCMMs) proposal by Vijay Saraswat [3] is a framework to express and study different declarative memory models. CCMMs are different from other proposals in that it does not express a memory model in terms of imperative operational semantics, but in terms of constraints. This should facilitate reasoning about the model and its properties, e.g. the no thin-air reads property is structurally proved in [3]. Because of the declarative constraint-based nature of CCMMs we have chosen constraint logic programming (CLP) as the technology for this generative implementation. In particular, JmmSolve has been implemented in the latest version of SWI-Prolog [4], with its new support for constraint programming: attributed variables and a Constraint Handling Rules (CHR) [1] system. CCMMs associate an event program with a source program. The event program is an abstraction that only keeps the relevant information for the memory model. Every statement in a source program corresponds with several events, i.e. read/write/lock/unlock/... operations on a source variable in a particular thread. Together with these events equality constraints are imposed over values read and written, e.g. for an assignment of an expression to a variable the value written to the variable should be equal to the expression. CCMMs models main memory as a constraint store that processes the events with their constraints. Events are processed in batches called action sets. Every thread can contribute any number of events with corresponding constraints to an action set. Such an action set is added as a whole by the store. The addition takes care of the following: The above three steps depend on the particular rules of the underlying ordering model. For example, the Sequential Consistency model only allows interleaved sequentialization of instructions, while the Happens Before model is more relaxed and imposes less ordering. CCMMs has set itself, in addition to the requirements of JSR-133, the requirement to be generative. This means that given a program it should be possible to generate all valid executions, in particular all valid linkings of reads to writes. It is the goal of JmmSolve to prove this point by providing exactly such a generative implementation of CCMMs. The current working of JmmSolve is as follows. A source program (in a simplified syntax) is read in and converted to an event program with constraints. The event program is partitioned into one action set for the initialization and one for all the threads. Both action sets are added to an empty store together with the necessary ordering constraints according to the memory model. Finally all valid linkings from reads to writes are generated for each action set. The compiler from source to event programs is rather straightforward, using DCGs. On the other hand, the generative part of JmmSolve, uses a mix of ordinary Prolog and CHR constraints. CHR constraints are used in particular: The current implementation of JmmSolve is available for download athttp://www.cs.kuleuven.ac.be/~toms/jmmsolve/ and contains rulesfor the Happens Before model.