Trying to cope with the constantly growing number of cores per processor, hardware architects are experimenting with modular non-cache-coherent architectures. Such architectures delegate the memory coherency to the software. On the contrary, high productivity languages, like Java, are designed to abstract away the hardware details and allow developers to focus on the implementation of their algorithm. Such programming languages rely on a process virtual machine to perform the necessary operations to implement the corresponding memory model. Arguing about the correctness of such implementations is not trivial though. In this work we present our implementation of the Java Memory Model in a Java Virtual Machine targeting a 512-core non-cache-coherent memory architecture. We shortly discuss design decisions and present early evaluation results, which demonstrate that our implementation scales with the number of cores. We model our implementation as the operational semantics of a Java Core Calculus that we extend with synchronization actions, and prove its adherence to the Java Memory Model.
@cite_35: The specification of the Java Memory Model (jmm) is phrased in terms of acceptors of execution sequences rather than the standard generative view of operational semantics. This creates a mismatch with language-based techniques, such as simulation arguments and proofs of type safety. We describe a semantics for the jmm using standard programming language techniques that captures its full expressivity. For data-race-free programs, our model coincides with the jmm. For lockless programs, our model is more expressive than the jmm. The stratification properties required to avoid causality cycles are derived, rather than mandated in the style of the jmm. The jmm is arguably non-canonical in its treatment of the interaction of data races and locks as it fails to validate roach-motel reorderings and various peephole optimizations. Our model differs from the jmm in these cases. We develop a theory of simulation and use it to validate the legality of the above optimizations in any program context.
Jagadeesan @cite_35 also describe an operational semantics for the Java Memory Model. Their work, however, does not account for caches or buffers. It abstracts away the hardware details and considers reads and writes to become actions that float into the evaluation context. This approach does not explicitly define when and where writes should be eventually committed to satisfy the JMM @. In our approach, we explicitly define where data get stored after any evaluation step.