1 / 28

Analyzing the CRF Java Memory Model

Analyzing the CRF Java Memory Model. Yue Yang Ganesh Gopalakrishnan Gary Lindstrom School of Computing University of Utah. Outline . Java Memory Model (JMM) introduction Why current JMM is broken Overview of the CRF JMM Our formal executable model Analysis results. Introduction of JMM.

cana
Télécharger la présentation

Analyzing the CRF Java Memory Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 Finally, can it result in a = 0?

  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

  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 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

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

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

  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@cs.utah.edu

  28. Thank You!

More Related