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 levelNeed 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 specificationJMM mailing list

• http://www.cs.umd.edu/~pugh/java/memoryModel

Replacement proposals• Manson and Pugh’s Model (JMMMP)

Based on set notation

• The CRF Model (JMMCRF) Commit / Reconcile / Fence

6

Motivations

Stronger capability of formal verificationMore uniform notationGreater flexibilityMore 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 JMMMP

8

UMM Conceptual Architecture

LIB – Local Instruction Buffer LV – Local Variable Array

GIB – Global Instruction Buffer LK – Lock Array

LIBjLIBi

ThreadjThreadi

LVi LVj

GIB

LK

9

Instruction Definition

<t, pc,op, var, data, local, useLocal, lock, time> • 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

Event Condition Action

readNormal iLIBt(i) :

ready(i) op(i) = ReadNormal

( wGIB: legalNormalWrite(i, w))

LVt(i)[local(i)] := data(w);

LIBt(i) := delete(LIBt(i), i);

writeNormal iLIBt(i) :

ready(i) op(i) = WriteNormal

if (useLocal(i))

i.data := LVt(i)[local(i)];

end;

GIB := append(GIB, i);

LIBt(i) := delete(LIBt(i), i);

13

Bypassing Policies

Controlled by table BYPASS

ready(i), iff jLIBt(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 are1) ordered by program order, 2) synchronized by the same lock or volatile variable, or3) 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 JMMMP

• 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 JMMOrdering Property

• Coherence• Write atomicity• Causality• Prescient write

Synchronization PropertyConstructor Property

18

Example: Prescient Write Behavior

Result: Yes Hence, anti-dependence (Read after

Write) is not guaranteed

Thread 1 Thread 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 implementationState 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

• http://www.cs.utah.edu/~yyang/research JMM mailing list archive

• http://www.cs.umd.edu/~pugh/java/memoryModel/

JSR-133: JMM and thread specification• http://jcp.org/jsr/detail/133.jsp

JSR-166: Concurrency utility• http://jcp.org/jsr/detail/166.jsp

23

Thank you!