Why STMs Need Compilers (a war story)

1. Why STMs Need Compilers(a war story) Maurice Herlihy Brown University

2. STM • Interested in managed languages • Java, C# • Not C, C++ • Synchronization based on objects, not addresses • Strong isolation between transactional & non-transactional access

3. STM Libraries: DSTM 2003 • Transactional “wrapper” for objects • Cumbersome & error-prone // wrapper for node object TMObject<RBNode> xnode= … // explicit open RBNode node = xnode.openRead(); // next field is wrapper TMObject<RBNode> next = node.next;

4. STM Libraries: SXM 2005 • Mark data types as atomic • Use reflection & run-time code generation • Not efficient (no global optimizations) [Atomic] // Atomic Red-Black Tree node public classRBNode { public int value; public Color color; public bool marked; public RBNode parent, left, right; public RBNode() { value = 0; color = Color.RED; parent = null; left = null; right = null; } }

5. Current work • Mark data types as atomic • Compiler does the rest… [Atomic] // Atomic Red-Black Tree node public classRBNode { public int value; public Color color; public bool marked; public RBNode parent, left, right; public RBNode() { value = 0; color = Color.RED; parent = null; left = null; right = null; } // other methods }

6. Optimizations • Whole object dataflow analysis • call tree for non-virtual methods • Pass context from method to method • Every method is analyzed for: • Local objects (not shared across transactions) • Read only or read/write objects • Promotes openReads to openWrites for RW objects • Early opens for objects used across basic blocks • Partial Redundancy Elimination (PRE)

7. Optimizations (cont.) • First vs. subsequent read/writes • Inline subsequent reads/writes with fast-path code sequence • Subsequent reads/writes are lock-free, even in the STM mode that uses short locks

8. Progress Conditions • Short-lived locks • Blocking • Efficient library implementation • Obstruction-free • No locks, non-blocking • Inefficient library implemenetation • After compiler optimizations, • obstruction-free performs as well as lock-based

9. Performance Comparison

10. Performance Comparison

11. Moral of the story • Libraries are either • Low-overhead but hard to use • Inefficient but easy to use • Compiler support • Combines best of both worlds • Non-local optimization