1. An Operational Approach to Relaxed Memory Models
Xinyu Feng
University of Science and Technology of China
Joint work with Yang USTC

2. Why Memory Models C1 || C2 Compiler Result
Which reads see which writes?
Memory

3. Two different philosophies for RMM
Define behaviors of all programs
Such as x86-TSO, JMM
DRF guarantee
Behaviors of racy programs
Weak, to incorporate main-stream optimizations
But not too week
Type safety, security, etc. , need to prohibit thin-air reads
Define behaviors of only DRF programs
C/C++11
But DRF with low-level atomics is difficult to understand

4. Operational Happens-Before Memory Model (OHMM)
Follows the first philosophy
Motivated by solving some of the problems of JMM
Use an abstract machine to simulate relaxed behaviors
Memory model defined as operational semantics
(Almost) Avoids thin-air reads
Avoids many surprising behaviors and bugs of JMM
Weak enough to allow common compiler optimizations

5. Basic settings Two types of memory cells: normal & volatile
Volatile read/write roughly corresponds to C++ load-acquire/store-release
Volatile memory cells cannot be used as normal ones
Unlike C++
This talk: non-volatile memory only

6. Design of the abstract machine
Starting from a SC machine
Adding 3 features to relax the program behaviors
Event buffers
History-based memory
Replay of events
Similar to [Yang et al. 2002]
New mechanism for compiler optimizations

7. The Abstract Machine - SCTn
processor
processor
memory

8. The Abstract Machine – Event BufferTn
00:00
timer
processor
processor
<<T1, t>, i>
<<Tn, t’>, i'>
event buffer
memory

9. Events and Event Buffer
Instructions are converted to events following the interleaving semantics:
<<t1, 0>, x = 1> t1 t2
<<t2, 1>, y = 1>
x = 1;
r1 = y;
y = 1;
r2 = x;
<<t2, 2>, r2 = x>
<<t1, 3>, r1 = y>

10. Events and Event Buffer
Events from the same threads could be reordered:
<<t1, 0>, x = 1> t1 t2
<<t2, 1>, y = 1>
x = 1;
r1 = y;
y = 1;
r2 = x;
<<t2, 2>, r2 = x>
<<t1, 3>, r1 = y>
Execution order: 2, 3, 0, 1
Result: r1 = r2 = 0

11. Limitation of Event Reordering
Reordering of events is not weak enough for the following program: t1 t2
Reorder is not allowed due to data dependency!
x = 1;
r1 = x;
x = 2;
r2 = x;
r1 = 2, r2 = 1 ?

12. The Abstract Machine – History-Based Memory
<<t1,0>, n1>
<<t2,1>, n2>
. . .
<<t2,3>, n3>
<<t1,4>, n4>
<<t2,5>, n5>
<<t1,7>, n7>
<<t1,9>, n9> T1 Tn
timer
00:00
processor
processor
<<T1, t>, i>
<<Tn, t’>, i'>
event buffer
A memory cell
memory

13. <<t1, 8>, r = x>
History-Based Memory
We keep all the write operations in the corresponding memory cell.
Update History of x
<<t1,0>, n1>
Read sees (1) the most recent write that happens-before it,
(2) or writes from other threads that does not happens-before it.
<<t2,1>, n2>
. . .
<<t2,3>, n3>
<<t1,4>, n4>
<<t2,5>, n5>
<<t1,7>, n7>
<<t1, 8>, r = x>
<<t1,9>, n9>

14. <<t1, 3>, r1 = x> <<t2, 4>, r2 = x>
History-Based Memory
Update History of x t1 t2
x = 1;
r1 = x;
x = 2;
r2 = x;
<<t1,1>, 1>
<<t2,2>, 2>
r1 = 2, r2 = 1 ?
<<t1, 3>, r1 = x>
<<t2, 4>, r2 = x>

15. Support of Compiler Analysis
Still cannot allow the following behavior:
Initially: x = 0, y = 0
r1 = x;
r2 = x;
if (r1 == r2)
y = 2;
r3 = y;
x = r3;
r1 = r2 = r3 = 2?

16. Compiler Optimization Can Be Smart
Initially: x = 0, y = 0
r1 = x;
r2 = x;
if (r1 == r2)
y = 2;
y = 2;
r1 = x;
r2 = r1;
if (true)
r3 = y;
x = r3;
r1 = r2 = r3 = 2?
Redundant read elimination
Must be allowed!

17. Support of Compiler Analysis
Still cannot allow the following behavior:
r1 = x;
r2 = x;
r1 = x;
r2 = x;
if (r1 == r2)
y = 2;
Our idea:
Use dynamic execution to simulate static analysis (or symbolic execution).
r3 = y;
x = r3;
Duplicate the first two lines.
r1 = r2 = r3 = 2?

18. The Abstract Machine - ReplayTn
timer
00:00
processor
processor
replay
replay
event buffer
memory

19. Replay Buffer r1 = x; r2 = x; if (r1 == r2) r3 = y; y = 2; x = r3;
Instead of code rewriting, we put an event into the replay buffer when they are executed, which can be executed a second time later.
r1 = x;
r2 = x;
if (r1 == r2)
y = 2;
r3 = y;
x = r3;
replay
r1 = x;
r2 = x;
Duplicate the first two lines.
event buffer
r1 = r2 = r3 = 2?
Need to be careful to preserve sequential semantics.

20. Some constraints for replay
When reads get replayed, its timestamp doesn’t change
r = x;
r = x;
x = r+1;
Cannot see the write

21. Some constraints for replay
When reads get replayed, its timestamp doesn’t change
When writes get replayed, the old writes in history is overwritten
<<t1,0>, n1>
<<t2,1>, n2>
. . .
<<t2,3>, n3>
<<t1,4>, n4>
<<t2,5>, n5>
<<t1,7>, n7>
<<t1,9>, n9>
Recall the update history stored in memory cells:
<<t1,4>, N >
You won’t end up having two events with same time stamp but different update value

22. Some constraints for replay
When reads get replayed, its timestamp doesn’t change
When writes get replayed, the old writes in history is overwritten
If a write have been seen by other threads, it cannot be replayed
<<t1,0>, n1>
false
true
. . .
<<t2,1>, n2>
. . .
<<t2,3>, n3>
<<t1,4>, n4>
Use Boolean flags to remember whether it has been seen (by others)
<<t2,5>, n5>
<<t1,7>, n7>
<<t1,9>, n9>

23. Necessary to prevent the following behavior:

24. Summary T1 Tn timer 00:00 processor processor event buffer memory
replay
replay
event buffer
memory

25. Properties of OHMM DRF-guarantee
DRF defined under SC semantics
(Almost) Passes JMM Causality Test Cases
Except two controversial ones (Test case 5 and 10)

26. Test case 5
JMM decides to prohibit it, but controversial in the mailing list (at least the value 1 does show in the program).

27. Properties of OHMM DRF-guarantee
DRF defined under SC semantics
(Almost) Passes JMM Causality Test Cases
Except two controversial ones (Test case 5 and 10)
Avoids some counter-intuitive/buggy behaviors of JMM [Aspinall & Sevcik, 2007]

28. vs.

29. Properties of OHMM DRF-guarantee
DRF defined under SC semantics
(Almost) Passes JMM Causality Test Cases
Except two controversial ones (Test case 5 and 10)
Avoids some counter-intuitive/buggy behaviors of JMM [Aspinall & Sevcik, 2007]
Soundness with respect to program transformations

30. Soundness w.r.t. Prog. Trans.
Results for SC, JMM and JMM-Alt taken from [Sevcik and Aspinall, ECOOP 2008]
JMM-Alt refers to [Aspinall and Sevcik, TPHOLs 2007], a fixed version of JMM
A grain of salt: transformations used for OHMM are defined syntactically, which are less general than their semantically-defined counterparts in [Sevcik and Aspinall, ECOOP 2008]

31. Summary OHMM Properties Event buffer, history-based memory, and replay
Supports DRF Guarantee (proved in Coq)
Weak enough to support compiler optimization
Thanks to the replay mechanism
No out-of-thin-air reads ?
Avoids surprising behaviors in JMM
Lockless programs have more relaxed semantics than JMM
Semantics of locks is stronger
Adding more synchronization reduces (instead of increases) behaviors

32. Thank you!