Transactional memory

1
Transactional memory garbage collection

• Tim Harris

2
The context

• Multi-cores are coming concurrent programs are
  no longer optional
• Yet the state of the art in concurrent
  programming is 30 years old locks and condition
  variables. (In C lock statements and
  Monitor.wait.)
• Locks and condition variables are fundamentally
  flawed its like building a sky-scraper out of
  bananas
• Races, deadlocks, lost wake-ups
• and still your code is non-composable

3
Atomic memory transactions
Like database transactions
Item Get() atomic ... sequential get code
...

• To a first approximation, just write the
  sequential code, and wrap atomic around it
• All-or-nothing semantics Atomic commit
• Atomic block executes in Isolation
• Cannot deadlock (there are no locks!)
• Atomicity helps error recovery roll back the
  atomic block if an exception escapes from it

4
Atomic blocks and GC
threads execution
Thread enters an atomic block
GC starts
Im assuming stop-the-world throughout this

• The GC must retain
• Objects that will be alive if the atomic block
  completes successfully
• Objects that will be alive if the atomic block is
  aborted
• The GC may deallocate
• Objects that are dead whether or not the atomic
  block completes successfully those that are
  allocated and die within the shaded region

5
Implementing atomic blocks
do StartTx() t ReadTx(o1.x)
WriteTx(o1.x, t1) while (!CommitTx()))
atomic o1.x

• (Eliding many details dealing with exceptions,
  concurrency between direct access and tx-access,
  )

Keep trying until we succeed (in reality add
back-off etc)
6
Implementing transactional memory

• Lots of schemes, heres one (PLDI 06)
• Automated 2-phase locking
• A transaction is implemented using logs of
• Objects it has written to transactionally
  (locking them before the first write)
• Objects it has read from transactionally (could
  take shared-reader locks, but may prefer
  optimistic concurrency control dependent on
  language)
• Values that it has overwritten (so they can be
  put back in the heap if the tx is aborted)

7
First approach

• Reduce to standard GC roll back all the
  transactions when GC starts
• OOPSLA 03, and a good fit for h/w TM
• Problem lack of progress

Well abort on every attempt
atomic r AllocIntensiveComputation()
8
Second approach

• Treat the logs as roots
• Haskell-STM (approx.)
• Problem bloat

Logging will keep t1 alive, even if its not used
in E1
atomic t1 AllocIntensiveComputation() //
Long computation E1
9
Bartok-STM (PLDI 06)

• Treat refs from logs as weak, except for
  overwritten values in the undo log
• Problem undo-log entries for tx-local objects,
  duplicate undo-log entries

atomic t1 AllocIntensiveComputation()
o1.x t1 t2 AllocIntensiveComputation()
o1.x t2 // Long computation E1
t1 kept alive because a ref to it is overwritten
10
Bartok-STM (PLDI 06)

• Track tx-local objects
• Write a special write locked value into an
  objects lock word when allocated inside a
  transaction
• Check for this special value before writing an
  undo-log entry for the object dont log updates
  to tx-local objects
• Track bitmaps of updates made
• Ordinary write locked values point to an entry
  in the tx write log
• Extend this log entry with a bitmap of which
  fields have been logged

11
Bartok-STM (PLDI 06)
Treat logs as roots
Track locals
Undo-log bitmap
Track locks undo-log bitmap
Normalised execution time
tree
go
skip
merge-sort
xlisp
12
Possible extensions

• Remove undo-log entries that would be silent
  stores

// Initially o1.x null atomic t1
ComputeTemporary() o1.x t1 // Long
computation E1 o1.x null // Long
computation E2
o1.xs restored to its old value discard the
undo-log entry for it
13
Possible extensions

• Write back undo-log entries if objects are dead
  if the transaction commits

Well log the old value of o2.x for roll-back
// o1.x holds only ref to o2 atomic o2.x
42 o1.x null // Big computation
but o2s now dead perform the roll-back early
and discard the log entry
14

• Links to papers etc
• http//research.microsoft.com/tharris
• Internships at MSR Cambridge (now all year around
  apply at any time, but we have a strict cut-off
  date for summer positions)
• http//research.microsoft.com/aboutmsr/jobs/inter
  nships/cambridge.aspx