DMITRI PERELMAN IDIT KEIDAR TRANSACT 2010 SMV: Selective Multi-Versioning STM 1

Agenda TRANSACT Introduction and problem statement  reduce the number of aborts  memory consumption  invisible reads SMV algorithm  keeps versions that can help save aborts  automatically removes others Preliminary evaluation  good for read-dominated workloads

Forceful aborts TRANSACT 2010 Aborting transactions is bad  work is lost  resources are wasted  overall throughput decreases  livelock 3

Unnecessary aborts TRANSACT 2010 Sometimes aborts are necessary  continuing the run would violate correctness And sometimes they are not  the suspicion is unjustified 4 o1 o2 C A necessary abort o1 o2 C A unnecessary abort T2 T1 T2 T3

Multi-Versioning in STM TRANSACT 2010 Keeping multiple versions can prevent aborts 5 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

GC challenge TRANSACT Must clean up the old versions Many 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 list of 5 past object versions Past versions are kept though they will never be read T1T2

Visibility challenge TRANSACT Changes in memory accessed by other transactions  demand the use of costly mechanisms (e.g., volatile variables) We want invisible readers  do not change data that can be read by others  avoid cache thrashing

Agenda TRANSACT Introduction and problem statement  reduce the number of aborts  memory consumption  invisible reads SMV algorithm  keeps versions that can help save aborts  automatically removes others Preliminary evaluation  good for read-dominated workloads

SMV design principles TRANSACT A txn is aborted if:  update txn: an object from the read-set is overwritten (like most other STMs existing today)  read-only txn: (almost) never – commits in a lock-free manner T i reads the latest object value written before T i starts Versions are kept as long as they might be needed Read-only transactions are invisible o1 o2 C C T1T2 o3 Start time snapshot

SMV design principles – GC challenge TRANSACT 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

Automated GC in SMV TRANSACT 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)

SMV time progress TRANSACT Logical version clock  incremented by update transactions upon commit  implemented as a linked list of time points Object handles  hold versioned locks ala TL2  point to the latest object version only time point 9time point 10time point 11 ver = 5 o1o1 data curPoint

Selective Multi-Versioning STM – overview TRANSACT 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 ver ≤ start time? T1T2 The value to be read

Selective Multi-Versioning STM – GC overview TRANSACT 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 Old versions are kept as long as they have potential readers  after that they are garbage collected automatically

“Unready” time points issue TRANSACT Committing transaction:  first inserts the new time point  then updates the write-set Potential problem: A similar problem is the reason for using locks + double checking in TL2 (each read is pre- and post-validated) curPoint time point 9 T2 ver = 5 o1o1 data 5 ver = 5 o2o2 data 5 time point 10 ver = 10 data 10 ver ≤ start time? reads o 1 and o 2 T1 writes o 1 and o 2 correctness violation! paused

“Unready” time points solution TRANSACT Each time point has a boolean ready flag  true when all the objects are updated readyPoint points to the latest time point in the ready prefix curPoint time point 9 ready = true T2 ver = 5 o1o1 data 5 ver = 5 o2o2 data 5 time point 10 ready = false ver = 10 data 10 ver ≤ start time? reads o 1 and o 2 T1 writes o 1 and o 2 consistent snapshot readyPoint paused

Limiting time point traversals TRANSACT The number of traversed time points might be large  a long read-only txn interleaves with a lot of short update txns Limit this number  the txn is aborted after traversing WindowSize time points Breaks the guarantee of unabortable read-only txns  but improves performance T1 …… WindowSize time point 9time point 10time point 11time point 59time point 60

Agenda TRANSACT Introduction and problem statement  reduce the number of aborts  memory consumption  invisible reads SMV algorithm  keeps versions that can help save aborts  automatically removes others Preliminary evaluation  good for read-dominated workloads

Preliminary evaluation – experiment setup TRANSACT STMBench7 evaluation framework – Java version  read-dominated and read-write workloads support Implemented the following algorithms:  SMV (WindowSize = 100)  SMVUnlimited (WindowSize = ∞)  TL2-style – mimics the basic behavior of TL2  k-versioned – each object keeps k versions (like in LSA) Did not use the software optimizations used in the original algorithms  common code platform for comparing the algorithmic issues only

Read-dominated workloads TRANSACT Emphasize the strong sides of SMV:  intensive use of old object versions by read-only txns  read-only txns do not need to traverse many time points

Read-write workloads TRANSACT Present the worst-case scenario for SMV:  update txns cannot leverage multiple versions (low commit-ratio)  read-only txns traverse long time point list suffixes (high overhead)

Memory consumption TRANSACT SMVUnlimited memory consumption is high because of long read-only txns Read-dominated workloadsRead-write workloads SMV memory consumption is low – for most of the objects keeps last version only

Further work TRANSACT Deuce framework  field-based synchronization  STAMP + STMBench7 benchmarks built-in Profiling  overhead vs. aborts rate GC threads in the non-managed environment  fine-tuned GC for txn objects

TRANSACT Thank you