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 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 Thread 1Thread 2 synchronized (this) { p = new Point(1, 2); } if (p != null) { a = p.x; } Finally, can it result in a = 0? Initially, p = null

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 Pugh’s 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 InstructionDescription LoadlLoad value from local cache StorelStore value to local cache CommitEnsure write back from cache to memory ReconcileEnsure update from memory to cache FenceEnsure ordering restrictions LockAcquire a lock UnlockRelease a lock FreezeComplete a final field operation

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: Java OperationTranslation Write a, v;Storel a, v; Commit a; v = Read a;Reconcile a; v = Loadl a;

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 Park’s 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 Ordering PropertiesResults Comparison with CoherenceCoherence is not enforced by CRF Comparison with PRAMPRAM is not enforced by CRF Prescient StoreAllowed only for non-aliased variables Write Atomicity Guaranteed by CRF CausalityNot enforced by CRF

19. Example: Test of Coherence  Result: Yes Coherence is not enforced by CRF Thread 1Thread 2 A = 1; A = 2; X = A; Y = A; Initially, A = 0 Finally, can it result in X = 2 & Y = 1?

20. Constructor Properties of CRF (Models the object escape scenario)  Result: it works only under certain conditions Must enforce data dependency for dereference EndCon must be ahead of the reference assignment Thread 1Thread 2 B = 1; EndCon; A = 1; X = A; Y = B; Initially, A = B = 0 (A: reference, B: field) Finally, can it result in X = 1 & Y = 0?

21. The Double-Checked Locking Algorithm public static Helper get() { if (helper == null) { synchronized (this) { if (helper == null) helper = new Helper(); } return helper; }  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 Thread 1Thread 2 EnterMonitor; X = A; B = 1; EndCon; A = 1; ExitMonitor; Y = A; Z = B; 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@cs.utah.edu

28. Thank You!