Analyzing the CRF Java Memory Model

1
Analyzing the CRF Java Memory Model

• Yue Yang
• Ganesh Gopalakrishnan
• Gary Lindstrom
• School of Computing
• University of Utah

2
Outline

• Java Memory Model (JMM) introduction
• Why current JMM is broken
• Overview of the CRF JMM
• Our formal executable model
• Analysis results

3
Introduction of JMM

• Language level support for multi-threading
• Need a memory model (thread semantics) to specify
  how threads interact
• Current Java Memory Model (JMM)
• Chap 17 of Java Language Specification
• Thread-local execution engine and working memory
• Threads interact via shared main memory
• Sets of actions constrained by different rules

4
Current JMM is broken

• Too strong
• Prohibits important compiler optimizations
• Too weak
• Object escaping from construction
• No specification for final fields

5
Example Object Escape Problem
Initially, p null
Finally, can it result in a 0?

• Result possible under the existing JMM
• Thread 2 is not synchronized ? Race Condition
• Some aggressive architecture allows p to be
  fetched from a stale cache line

6
The Bad Consequence

• Immutable objects are not truly immutable
• Changing the field type to final does not help
• /tmp/system might be read as /system
• Serious security hole
• Popular programming patterns are broken
• e.g., double-checked locking algorithm

7
Challenging JMM Issues

• Maintain safety guarantees
• Support multiple architectures
• JMM designers - identify reasonable requirements
• JVM implementers - ensure compliance
• Cover all related language semantics
• Final / volatile fields, constructors,
  finalizers, etc.
• Deal with run-time complexities
• Aliasing, dynamic method invocation, etc.

8
New Replacement Proposals

• Bill Pughs model
• The CRF model
• By Maessen, Shen, and Arvind at MIT

9
CRF JMM Overview

• CRF stands for Commit / Reconcile / Fence
• Java memory operations are translated into
  fine-grained CRF instructions
• Java memory model is specified by CRF rewrite
  rules and reordering rules

10
CRF Instructions
11
Java to CRF Translation

• Two kinds of memory operations
• Read / Write operations
• Defined based on variable types Regular / Final
  / Volatile
• Synchronization operations
• Enter lock / Exit lock / EndCon
• Example

12
CRF Rewrite Rules

• CRF local rules
• Operational semantics for CRF instructions
• Only affect local cache
• CRF background rules
• Synchronize cache and shared memory

13
CRF Ordering Rules(Blank entries may be
reordered)
14
Our Formal Executable Model

• Inspired by Dill and Parks work on SPARC
• Implemented as Mur? rules and functions
• Two logical components
• The CRF JMM engine
• Acts as a black box that defines thread semantics
• A test suite
• Each test is designed to reveal a specific
  property

15
The CRF JMM Engine

• Local rules
• Randomly choose one eligible instruction
• Guarding conditions enforce reordering rules
• Execute it according to the CRF local rules
• Background rules
• Purge (unmap a cache entry)
• Cache (update cache from memory)
• Write Back (update memory from cache)
• Acquire/Release locks

16
The Test Suite

• Add test cases via Mur? Startstates
• Setup thread instructions for each test case
• Java to CRF translation is automated by
• Procedure AddInstruction
• Two ways to check results
• Output single violation trace (use Mur?
  invariants)
• Output all interleaving results (use special
  completion rules)

17
Analysis of the CRF JMM

• Ordering properties
• Constructor properties
• Synchronization idioms

18
Ordering properties of CRF
19
Example Test of Coherence
Initially, A 0
Finally, can it result in X 2 Y 1?

• Result Yes
• Coherence is not enforced by CRF

20
Constructor Properties of CRF(Models the object
escape scenario)
Initially, A B 0 (A reference, B field)
Finally, can it result in X 1 Y 0?

• Result it works only under certain conditions
• Must enforce data dependency for dereference
• EndCon must be ahead of the reference assignment

21
The Double-Checked Locking Algorithm

• Commonly used for Singleton (created once)
  objects
• Tries to limit locking overhead to the
  constructing thread
• Broken under the current JMM (object escape
  problem)

22
Test for Double-Checked Locking
Initially, A B 0 (A reference, B field)
Finally, can it result in X 0 Y 1 Z 0?

• Result test successfully passed
• The presence of EndCon is essential
• A closely related version (without EndCon) would
  be broken

23
Usage of Our Framework

• Helpful for understanding JMM
• JMM designers can use it as a powerful debug
  tool
• Users can treat the JMM as a black box
• Gaining extra confidence
• Checking programming idioms
• Checking compiler transformation patterns
• Comparison with conventional models
• A well designed test suite can be served as a
  valuable QA benchmark

24
Discussion - Advantages

• Executable model
• See effects of changes immediately
• Exhaustive enumeration
• Reveal subtle corner cases
• Rigorous specification
• Reduce ambiguities

25
Discussion - Limitations

• State explosion
• More complex language features not supported yet
• Thread creation, termination, interruption, etc.

26
Future Directions

• JMM implication for compiler optimizations
• Synchronization optimizations
• Dependency Analysis
• JMM implication for hardware architectures
• Targeting real Java code
• Abstraction / slicing techniques
• Pattern annotation / recognition techniques

27
Links to Related Resources

• JMM discussion group
• http//www.cs.umd.edu/pugh/java/memoryModel
• JMM and Thread Specification Revision
• JSR-133 (http//jcp.org/jsr/detail/133.jsp)
• Our Mur? program
• http//www.cs.utah.edu/yyang/research/crf.m
• Our email yyang_at_cs.utah.edu

28
Thank You!