Pay-to-use strong atomicity on conventional hardware Martín Abadi, Tim Harris, Mojtaba Mehrara Microsoft Research

Our approach Strong semantics atomic, retry,..... What, ideally, should these constructs do? Programming discipline(s) What does it mean for a program to use the constructs correctly? Low-level semantics & actual implementations Transactions, optimistic concurrency, program transformations, weak memory models,...

Programming disciplines All programs Violation-free programs Obeying dynamic separation Obeying static separation More implementation flexibility More programs correctly synchronized Which programs are correctly synchronized?

Strong atomicity Direct accesses work like single-access transactions We would like: –Implementation flexibility; ongoing innovation in STM/hybrid techniques, optimizations,... Invisible / visible readers In-place / deferred updates Eager / lazy conflict detection –No overhead on direct accesses –Robust performance, not dependent on success of static analyses

Strong atomicity: implementation Physical address space Virtual address space Tx-heapDirect-heap Direct memory accesses Memory accesses from atomic blocks

Writes from atomic blocks Physical address space Virtual address space Tx-heapDirect-heap Direct memory accesses Memory accesses from atomic blocks 1. Atomic block attempts to write to a field of an object

Writes from atomic blocks Physical address space Virtual address space Tx-heapDirect-heap Direct memory accesses Memory accesses from atomic blocks 2. Revoke direct access to the page holding the direct view of the object

Writes from atomic blocks Physical address space Virtual address space Tx-heapDirect-heap Direct memory accesses Memory accesses from atomic blocks 3. Use underlying STM write primitives

Writes from atomic blocks Physical address space Virtual address space Tx-heapDirect-heap Direct memory accesses Memory accesses from atomic blocks 4. Restore direct access once the underlying transaction has finished and an access violation (AV) occurs

Avoiding Access Violations 1.Safe accesses in runtime system code –Virtual method tables and array length –Memory allocation structures (e.g. free list) –STM implementation structures –GC implementation Forward all these to TX- heap at compile time

Avoiding Access Violations 2.Safe accesses in normal code –Normal writes to locations that haven’t been read or written in a TX –Normal reads from locations that haven’t been written in a TX 3.Safe accesses in TX code –TX writes to locations that haven’t been read or written outside TXs –TX reads from locations that haven’t been written outside TXs Forward to TX-heap Avoid page-level tracking

Sample Code private int ComputeUniqueSegments (int nthreads) { int numUniqueSegment = 0; for (int i = 0; i < nthreads; i++) numUniqueSegment += this.uniqueSegments[i].Count; return numUniqueSegment; } Genome_Sequencer_ComputeUniqueSegments:: loop: mov eax,dword ptr [edi+0x20] // Load uniqueSegments array reference cmp ebx,dword ptr [eax+0x4] // Check reference with array bounds jae outOfRange mov ecx,dword ptr [eax+ebx*4+0x08] // load array element mov eax,dword ptr [ecx] // load Count function pointer call dword ptr [eax+0x88] // call Count (get) function add ebp,eax// add it to numUniqueSegments add ebx,1 cmp ebx,esi jl loop Access immutable runtime- system data cmp ebx,dword ptr [eax+0x ] // Check reference with array bounds mov eax,dword ptr [ecx+0x ] // load Count function pointer call dword ptr [eax+0x ] // call Count (get) function mov ecx,dword ptr [eax+ebx*4+0x ] // load array element mov eax,dword ptr [edi+0x ] // Load uniqueSegments array reference Safe normal access

Exploiting Safe Accesses Implemented by extending Steensgard’s points- to analysis Only safe accesses from normal code were beneficial Little benefit from identifying safe accesses from inside atomic blocks. #page-table changes: GenomeDelaunayLabyrinthVacation Before31 K K After31 K K Ratio99%90%36%92 %

Patching access violations Patch sites of AVs Our heuristic: –Patch on first AV –Also change page protection as normal Future work: –Remove patches if they become unnecessary –Make multiple patches to bound worst-case perf

Results - Vacation

Results - Delaunay

Results - Genome

Results - Labyrinth

Scaling SA – patch AV + analysis WA

Conclusion Weak atomicity is an obstacle in providing clear semantics for TM models We use conventional memory protection hardware to provide strong atomicity This comes at a low performance cost… high runtime complexity cost Performance hit can be lowered by compile time analysis