1. IDIT KEIDAR DMITRI PERELMAN RUI FAN EuroTM 2011 Maintaining Multiple Versions in Software Transactional Memory 1

2. Aborts in STM EuroTM 2011 Forceful aborts – an algorithm suspects correctness violation Aborting transactions is bad  work is lost  resources are wasted  overall throughput decreases  danger of livelock 2

3. Multi-versioning in STM EuroTM 2011 Keeping multiple versions can prevent aborts 3 o1 o2 CC cannot read the latest version – read the previous one o1 o2 C cannot read the latest version – abort A T1T2T1T2 Single-versioned STMMulti-versioned STM

4. GC challenge EuroTM 2011 4 Must clean up the old versions Some existing TMs keep a list of n past versions  some kept versions are useless  some potentially useful versions are removed o1 o2 The sixth version is removed The needed version has been removed A TM keeps the last 5 versions Past versions are kept though they will never be read T1T2

5. Memory growth EuroTM 2011 5 k versions => k times more memory?  No! It can be much worse…  Consider pointer-based data structures 102030102040 30 102540 3020 10 2550 30 20 40 10 25 60 30 20 40 50 replace 30 with 40 replace 20 with 25 replace 40 with 50 replace 50 with 60 Complete binary tree for a linked list

6. Permissiveness in multi-versioned STM EuroTM 2011 Multi-Versioned (MV)-Permissiveness  each read-only transaction commits  an update transaction aborts only if it conflicts with another update transaction Practical – satisfied by Vboxes, SMV  would have been achieved by most multi-versioned algorithms  if they had kept all the needed object versions Responsive STM  a txn operation does not wait for other transactions to invoke new txn operations  to avoid trivial “global lock” solutions (no aborts and no concurrency) 6

7. Space optimality for MV-permissiveness EuroTM 2011 7 Space optimality  An MV-permissive STM1 is space optimal if for any MV- permissive STM2 at any point of time:  #versions in STM1 ≤ #versions in STM2 No responsive MV-permissive STM can be space optimal Sometimes, it’s impossible to know whether to remove an old version  could save the need to keep other versions in future

8. MV permissiveness vs DAP EuroTM 2011 Disjoint Access Parallelism (DAP) property: txns with disjoint data sets do not contend (no “common bottleneck”) A responsive MV-permissive STM cannot be DAP Intuitively, contention point is “responsible” for real- time order guarantee  can forfeit RTO and satisfy DAP 8

9. SMV: Selective Multi-Versioning STM EuroTM 2011 9 Responsive and MV-Permissive  each read-only transaction commits  cannot be space-optimal  cannot be DAP Versions are kept as long as they might be needed Read-only transactions are invisible to other transactions  do not change data that can be read by others  avoids cache thrashing

10. GC challenge EuroTM 2011 10 No transaction can know whether a given version can be removed  explicit GC is not possible A version is removed when it has no potential readers Readers are invisible o1 o2 C T1T2 o1 o2 C T2 Kept Removed Indistinguishable

11. Automated GC in SMV EuroTM 2011 11 Solution: use auxiliary GC threads provided by managed memory systems  remove unreachable object versions Read-only transactions are invisible to other transactions, but visible to the “see-all” GC threads  theoretically visible  practically invisible  GC threads run infrequently  does not add cache-coherency overhead

12. SMV overview EuroTM 2011 12 curPoint time point 9 T1 ver = 5 o1o1 data 5 o1 o2 ver = 5 o2o2 data 5 C time point 10 ver = 10 data 10 T1T2 weak references to prev versions ver ≤ start time? The value to be read

13. SMV GC EuroTM 2011 13 curPoint time point 9 o1o1 data 5 o1 o2 o2o2 data 5 C time point 10 ver = 10 data 10 C time point 11 T1T2 T1 Unneeded versiones are GCed automatically

14. SMV performance EuroTM 2011 14 Great for read-dominated workloads  especially with long read operations (snapshot, aggregation, etc.) Low overhead if there are no read-only transactions at all STMBench7 read-dominatedVacation

15. Conclusions EuroTM 2011 15 Multi-versioning can improve STM performance  especially useful for long read-only transactions Keeping a constant number of versions is not efficient  not every needed version can be found  exponential memory growth MV-permissiveness imposes overheads of its own  cannot be space efficient  cannot be DAP SMV uses automatic GC capabilities for deleting old versions  the readers stay invisible

16. References EuroTM 2011 16 On Maintaining Multiple Versions in STM  Perelman, Keidar, Fan, PODC’10 SMV: Selective Multi-Versioning STM  Perelman, Byshevsky, Litmanovich, Keidar, submitted