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

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

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

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 class RBNode { 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; }

Current work Mark data types as atomic Compiler does the rest… [Atomic] // Atomic Red-Black Tree node public class RBNode { 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 }

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)

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

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

Performance Comparison

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