1. Steal-on-abort Improving Transactional Memory Performance through Dynamic Transaction Reordering Mohammad Ansari University of Manchester

2. Motivation Conflicts are bad Reduce application performance/scalability If abort occurs: waste computing resources Conflicts should be minimised TM implementations assume conflicts are rare Often optimise for commits Making conflicts and aborts expensive

3. Motivation TM applications likely to have conflicts TM aimed at ‘average programmer’ Unlikely to have expertise to minimise conflicts Exacerbated as number of cores rises It would be nice to automatically reduce conflicts Improve performance transparently No (or minimal) programmer effort Steal-on-abort (SOA) Automatically attempts to reduce repeat conflicts Repeated conflict between two particular transactions

4. Repeat Conflicts: Example T1 and T2 execute concurrently T1 conflicts with T2 T1 aborts T1 restarts (immediately) T1 conflicts with T2 again T1 aborts again T1 restarts (immediately) T1 conflicts with T2 again … T2 T1 …

5. SOA Motivation In general, difficult to predict first conflict/abort Once observed, simple to avoid next conflict/abort Do not execute T1 & T2 concurrently Steal-on-abort design: Prevent repeat conflict: On abort, abortee transaction stolen (hidden) by aborter Abortee transaction released after aborter commits Additionally, attempt to improve performance: Thread whose transaction is stolen obtains another transaction to execute. May commit, improving performance.

6. SOA Trade-offs Advantages: No offline processing required Application-agnostic, no programmer input needed Low overhead, only acts upon abort Disadvantages: Unsuitable for invisible reads and writes

7. SOA Implementation Three components: Threads with job deques Work stealing between job deques Steal-on-abort action

8. Threads with Job Deques

9. Work Stealing in Action

10. Steal-on-Abort in Action

11. Evaluation 4x dual-core (8-core) Opteron system DSTM2 with Polka contention manager Port of STAMP’s Vacation benchmark Parameters changed to induce high contention Results from average of 9 runs

12. Time Spent in Aborted Transactions

13. Performance

14. Repeat Conflict Distribution

15. Overhead Analysis

16. Summary Conflicts hurt performance, may waste resources Repeat conflicts can be a source of conflicts/aborts Steal-on-abort attempts to reduce repeat conflicts Aborter steals abortee, releases once committed Abortee’s thread acquires new transaction Completely transparent, but requires visible accesses Evaluation Performance, resource usage improvements Low overhead

17. Repeat Conflict Distribution (log scale)

18. SOA: Example T1 conflicts with T2 T1 aborts T3 starts T1 T2 T3

19. Threads with Job Deques Thread A Job 0 Job 1 Job 2 Job 3 currentJob mainDeque currentJob

20. Threads with Job Deques Thread AThread B Job 4 Job 5 Job 6 Job 7 currentJob mainDeque currentJob