Supporting Nested Transactional Memory in LogTM

1. Supporting Nested Transactional Memory in LogTM Authors Michelle J Moravan Mark Hill Jayaram Bobba Ben Liblit Kevin Moore Michael Swift Luke Yen David Wood Presented By Shweta Padubidri

2. OVERVIEW • Common Terms • LogTM • LogTM with nested Transactions • Experiment • Conclusion

3. Introduction • Transactional Memory • Concurrency control mechanism to control access to shared memory in concurrent computing • Allows a group of load and store instructions in an atomic way • Nested Transactional Memory • a new transaction started by an instruction already inside an existing transaction • Transaction Isolation: Changes made by nested transactions are not seen by the 'host' until it is committed.

4. Transactional Memory System • Transactional Memory Systems Differences • (Data) Version Management • Eager: record old values “elsewhere”; update “in place” • Lazy: update “elsewhere”; keep old values “in place” • (Data) Conflict Detection • Eager: detect conflict on every read/write • Lazy: detect conflict at end (commit/abort)

5. 1 1 1 1 34------------ -- ------------ --23 Log Based TM Version Management • New values stored in place (in main memory) • Old values stored in a thread-private transaction log VA Data Block R W 00 12-------------- 0 0 40 --------------24 --------------23 0 0 C0 56-------------- 34-------------- 0 0 LogBase 1000 LogPtr 1090 1000 c0 TMcount 1040 40 1 1080

6. Log Based TM

7. Log Based TM • Version Management • When a commit occurs the LogTM processor clears its cache’s W bits and resets the thread’s log pointer • Drawback : aborts are slow • Abort: LogTM must undo the transaction by writing old values back • Reset the R/W bits • Undo proceeds from end of the log to the beginning (LIFO)

8. Example

9. Log Based TM • Conflict Detection • Requesting processor sends a coherence request to the directory • Directory responds and forwards the request to one or more processors • Each responding processor examines local state to detect conflict • Responding processors either ack(no conflict) or nack(conflict) the request • Requesting processor resolves any conflict

10. Log Based TM

11. Nested LogTM • Motivation • Facilitating Software Composition • Closed Nesting • transactions remain isolated until parent commits • Partial Aborts improve performance • Enhancing Concurrency • Open Nesting • transactions commit independent of parent • Manages isolation at a higher level of abstraction

12. Nested LogTM • Motivation (Contd) • Escaping to Non-Transactional Systems • Supports calls to lower level non-transactional system ( eg: OS), from within a transaction with escape actions.

13. Version Management in Nested LogTM • Closed Nesting • Flat • Nested transactions “flattened” into a single transaction • Only outermost begins/commits are meaningful • Any conflict aborts to outermost transaction • Partial Rollback • Child transaction can be aborted independently • Can avoid costly re-execution of parent transaction • But child merges transaction state with parent on commit • Most conflicts with child end up affecting the parent

14. Version Management in Nested LogTM • Flat LogTM’s log is a single frame (Fixed Size header + undo records) • Nested LogTM’s log is a stack of frames • A frame contains: • Header (including saved registers and pointer to parent’s frame) • Undo records (block address, old value pairs) • Garbage headers (headers of committed closed transactions) • Commit action records • Compensating action records

15. Version Management in Nested LogTM • The Log Structure Header LogBase LogFrame Undo record LogPtr Undo record TM count Header 2 1 Undo record Undo record

16. Closed Nested Commit • Merge child’s log frame with parent’s • Mark child’s header as a “garbage header” • Copy pointer from child’s header to LogFrame Header LogFrame Undo record LogPtr Undo record Header TM count 1 2 Undo record Undo record

17. Nested LogTM • Flat LogTM detects conflicts with directory coherence and Read (R ) and Write (W ) bits in caches • Nested LogTM replicates R/W bits for each level • Flash-Or circuit merges child and parent R/W bits

18. Example

19. Example

20. Concurrency • Higher-level atomicity • Child’s memory updates not undone if parent aborts • Use compensating action to undo the child’s forward action at a higher-level of abstraction • Higher-level isolation • Release memory-level isolation • Programmer enforce isolation at higher level (e.g., locks) • Use commit action to release isolation at parent commit

21. Open Nesting • Commit Actions • Execute in FIFO order when innermost open ancestor commits • Compensating Actions • Discard when innermost open ancestor commits • Execute in LIFO order when ancestor aborts

22. Open Nesting Condition Condition O1: An open nested child transaction never modifies a memory location that has been modified by any ancestor. // initialize to 0 counter = 0; transaction_begin(); // top-level 1 counter++; // counter gets 1 open_begin(); // level 2 counter++; // counter gets 2 open_commit(abort_action(counter--)); ... // Abort and run compensating action // Expect counter to be restored to 0 ... transaction_commit(); // not executed

23. Open Nesting in LogTM • Version Management • Open commit pops the most recent frame off the log • (Optionally) add commit and compensating action records • Compensating actions are run by the software abort handler • Conflict Detection • R/W bits cleared on open commit • No ‘OR’ of the R/W bits occur

24. Example

25. Escape Actions • Escape actions are used to implement low-level functions (eg: exception handlers, debuggers and other run-time support) but are hidden from high level programmers • Low level escapes to software that is non-transactional (no atomicity or isolation) • May not invoke a transaction • May register commit and compensating actions • Have no effect on the enclosing transactions • It increases the variety of code that execute within transactions

26. Escape Action • Rules Escape Actions need to Obey • Condition X1: No writes to Data Written by Ancestors • Conditions X2: No Writes to Data Accessed by Others • Condition X3: No Reads to Data Written by Others

27. Escape Action in LogTM • Version Management • No changes are made to the log. Read and Write access coherent memory to return the value from the latest uncommitted write • Conflict Detection • No changes are made to the Read and Write bits • Implements escape actions with a per thread flag, which disables logging and conflict detection when set. • If an ancestor transaction aborts while the escape action is running , abort is delayed until the flag is cleared.

28. Experiment • BTree Micro benchmark • Each Thread makes a repeated access to a shared tree • Lookup Probability(85%) and Insert(15%) • Each insert or lookup is executed as a top level transaction • New nodes are allocated from a shared free list using pen and closed nested transaction

29. B-Tree: Closed Nesting

30. B-Tree: Open Nesting

31. Conclusion • Closed Nesting (partial rollback) • Easy to implement--segment the transaction log (stack of log frames)/Replicate R & W bits • Small performance gains for LogTM • Open Nesting • Easy to implement--software abort handling allows easy execution of commit actions and compensating actions • Big performance gains • Escape Actions • Provide non-transactional operations inside transactions

32. Questions ???