A Case for Deconstructing Hardware Transactional Memory Systems

1. A Case for Deconstructing Hardware Transactional Memory Systems Mark D. Hill, Derek Hower, Kevin E. Moore, Michael M. Swift, Haris Volos, David A. Wood LogTM Project (www.cs.wisc.edu/multifacet/logtm/) Computer Sciences Dept., Univ. of Wisconsin—Madison September 2007 @ Dagstuhl Seminar 07361 Architects should not develop programming models Instead let’s discuss hardware support

2. Executive Summary • Transaction Memory promising & Hardware TM (HTM) fast • But HW vendors cautious about HTM • Implementation choices in flux • Ultimate TM success not assured • Thesis: Facilitate TM adoption by deconstructing HTMs into components that are separate, interchangeable, & re-usable • Deconstruction aids HTM refinement • E.g., Special cache  Write buffer  HW logging  SW logging • Deconstruction enables use beyond TM • E.g., Recording for deterministic replay  Deconstruction to promote TM & other models Wisconsin Multifacet Project

3. Outline (1) Deconstruction Aids HTM Refinement • Herlihy & Moss • GRAAS Deconstruction • Rollback Evolution • Access Check Evolution (2) Deconstruction Beyond TM Wisconsin Multifacet Project

4. Herlihy & Moss TM (HMTM) • Seminal work • TM data in special cache • No change to coherence protocol • But • Transactions can’t exceed special cache size • Livelock possible • Let’s deconstruct to improve…. Wisconsin Multifacet Project

5. } Talk Focus A GRAAS (“grass”) Deconstruction • Grouping: Demark a finite set of instructions • Rollback: Undo a set of instructions • Access Summary: Record read/write set • Access Check: Check for conflicts • Scheduling: Choose who executes & when Wisconsin Multifacet Project

6. Rollback • Save old values (for abort) & new values (for commit) • HMTM: Flush special cache; no register rollback • SLE: Speculative processor • TCC write buffers • LTM/Bulk cache incoherence • LogTM/SigTM log(per-thread in virtual memory) • Aids commit, cache victimization, & thread migration • “Best” design still in flux? Wisconsin Multifacet Project

7. Access Summary • Summarize read/write sets for detecting conflicts • HMTM special cache • SLE/LTM/LogTM cache states • TCC block/word cache states • Bulk/LogTM-SE/SigTM signatures • “Best” design still in flux? Wisconsin Multifacet Project

8. Recommendation to HW Vendors • Deconstruct HTMs facilitate TM evolution • Examples from GRAAS deconstruction • Rollback: Write buffer  HW logging  SW logging • Access Summary: Special Cache (States)  Signatures • More Innovations TBD Wisconsin Multifacet Project

9. Outline (1) Deconstruction Aids HTM Refinement (2) Deconstruction Beyond TM • Deterministic Replay • GRASS Beyond TM • Call for Innovation Wisconsin Multifacet Project

10. Example: Deterministic Replay • … for debugging, fault-tolerance, & security audits • Existing Flight Data Recorder • Logs 1B/1K-instuctions for conflicting memory accesses • Requires timestamp cache, e.g., 24KB/core • Transactional Flight Data Recorder • Log transaction order – no timestamp cache • Use minimal HW for non-transaction conflicts (if exist) • FDR & TM synergy may help both be adopted Wisconsin Multifacet Project

11. GRAAS Beyond TM Wisconsin Multifacet Project

12. Call for Innovation • TM deconstruction aids programming • Can decontruction aid parallel programming models? • Don’t assume symmetric multiprocessor hardware • Let’s dream of • Parallel programming models • Facilatated by new hardware mechanisms Wisconsin Multifacet Project

13. Executive Summary • Facilitate TM adoption by deconstructing HTMs into components: separate, interchangeable, & re-usable • Deconstruction aids HTM refinement • Deconstruction enables use beyond TM • Deconstruction to promote TM & other models References http://www.cs.wisc.edu/multifacet/logtm/ ./multifacet/papers/tr1594_dtm.pdf ./multifacet/papers/ieeemicro07_flight_data_recorder.pdf Wisconsin Multifacet Project