Specifying Java Thread Semantics Using a Uniform Memory Model Jason Yue Yang Ganesh Gopalakrishnan Gary Lindstrom School of Computing University of Utah

2 Multithreading in Java  Supported at language level  Need a formal memory model (thread semantics)  Current JMM Java Language Specification, Chap 17 It is broken

3 Problems with the Current JMM  Too strong Strict ordering constraints Strict synchronization visibility requirements  Too weak Reference escaping prematurely from constructor Final field specification omitted Volatile variable operations have no visibility requirement on normal variable operations

4 Example: Double-Checked Locking Idiom is Broken class foo { private static Resource resource = null; public static Resource get() { if (resource == null) { synchronized (this) { if (resource == null) resource = new Resource(); } return resource; }

5 Improvement Efforts  JSR-133: JMM and thread specification  JMM mailing list  Replacement proposals Manson and Pugh’s Model (JMM MP )  Based on set notation The CRF Model (JMM CRF )  Commit / Reconcile / Fence

6 Motivations  Stronger capability of formal verification  More uniform notation  Greater flexibility  More comprehensive support for language level models E.g., local variable behaviors in thread interactions

7 UMM (Uniform Memory Model)  Abstract transition system Memory model specified as guarded commands Executable with an integrated model checker  Flexible configuration Can specify various memory models  Uniform architecture Parameterizes differences among memory models  Semantics primarily based on JMM MP

8 UMM Conceptual Architecture LIB – Local Instruction Buffer LV – Local Variable Array GIB – Global Instruction Buffer LK – Lock Array LIB j LIB i Thread j Thread i LV i LV j GIB LK

9 Instruction Definition  t: issuing thread pc:program counter op: operation type var: variable data:data value local:local variable useLocal:tag for using local variable lock:lock time:global time stamp

10 Critical Memory Model Properties  Program order Instruction order determined by software  Visibility order Final observable order perceived by threads  Mutual exclusion

11 General Strategy in UMM  Enabling mechanism Program order may be relaxed to enable certain interleaving Controlled via bypassing table  Filtering mechanism Legal execution trace constructed from GIB following proper ordering requirements Enforced in read selection rules

12 Transition Table Example : read and write operations EventConditionAction readNormal  i  LIB t(i) : ready(i)  op(i) = ReadNormal  (  w  GIB: legalNormalWrite(i, w)) LV t(i) [local(i)] := data(w); LIB t(i) := delete(LIB t(i), i); writeNormal  i  LIB t(i) : ready(i)  op(i) = WriteNormal if (useLocal(i)) i.data := LV t(i) [local(i)]; end; GIB := append(GIB, i); LIB t(i) := delete(LIB t(i), i);

13 Bypassing Policies  Controlled by table BYPASS  ready(i), iff   j  LIB t(i) : pc(j) < pc(i)  (localDependent(i, j)  BYPASS[op(j)][op(i)] = No)

14 Condition legalNormalRead  Enforces Serialization Read gets data from the most recent previous write  legalNormalRead(i), iff op(w) = WriteNormal  var(w) = var(r)  (   w’  GIB : op(w’) = WriteNormal  var(w’) = var(r)  ordered(i, w’)  ordered(w’, w) )

15 The Ordering Requirement  Operations i1 and i2 are ordered, iff they are 1)ordered by program order, 2)synchronized by the same lock or volatile variable, or 3)transitively ordered by another intermediate operation  ordered(i1, i2), iff programOrdered(i1, i2)  synchronized(i1, i2)  (  i’  GIB : ordered(i1, i’)  ordered(i’, i2) )

16 UMM Implementation in Mur   The JMM engine Precisely defines the thread semantics Primarily based on semantics of JMM MP Implemented as Mur  rules and functions  Test Suite Carefully picked test cases Captures the essence of interesting properties Implemented with corresponding Mur  initial states and invariants

17 Analysis of the JMM  Ordering Property Coherence Write atomicity Causality Prescient write  Synchronization Property  Constructor Property

18 Example: Prescient Write Behavior  Result: Yes  Hence, anti-dependence (Read after Write) is not guaranteed Thread 1Thread 2 r1 = a; a = 1; r2 = a; a = r2; Initially, a = 0 Finally, can it result in r1 = 1 & r2 = 1?

19 Benefits  Support for formal verification Executable style – finds results immediately Exhaustive enumeration – reveals corner cases Rigorous specification – reduces ambiguities  Generic and uniform interface Enables configuration and comparison  Simple architecture Eliminates architecture-specific complexities

20 Limitations  Not intended to be the actual implementation  State explosion problem Limited to simple test cases

21 Ongoing Efforts  Comprehensive coverage for many common memory models  Support for theorem proving technique

22 For More Information …  UMM prototype  JMM mailing list archive  JSR-133: JMM and thread specification  JSR-166: Concurrency utility

23 Thank you!