Large, Unbounded, and Virtual Transactional Memory

1
Large, Unbounded, and Virtual Transactional Memory

• Chris Chaney
• Chris Thomas

2
Motivation

• Locks have lots of downsides
• We all know them by now
• Software transactional memory is slow
• Architectural limits on transaction size are bad
• Time, space, etc.

3
LTM

• Common case handle by some other hardware
  transactional memory proposal
• Adds extra support to handle cache overflows
  (with OS support)
• Supports transactions up to size of physical
  memory
• No nested transactions

4
LTM
5
LTM Hardware Modifications

• Two extra bits in cache tags
• Overflow base register added to architectural
  state
• Existing cache coherence protocols handle
  conflict detection

6
LTM - Performance

• Microbenchmark simulated on multiprocessor
  simulator
• Transactions demonstrated much better scalability
• SPECjvm98 simulated on uniprocessor simulator
• Showed that very little time was spent in
  overflow
• Transaction performance measurement is odd, given
  single-threaded machine
• Other trace-based analysis showed 99.9 of
  transactions used lt54 cache lines

7
UTM

• Common case still some other fast hardware scheme
• Still requires OS support
• Supports transactions up to almost virtual memory
  size
• Transcations can switch processors, and can run
  over multiple timeslices
• Still no nested transactions

8
UTM

• Rolls back processor state on abort
• Memory state maintained via xstate data
  structure
• a log per transaction
• transaction log contains old values of memory
  locations
• transactional load/stores to each memory block
  form a linked list (i.e. one list per memory
  block)
• requires a pointer per memory block
• gets messy (and slow) when you have
  non-transactional memory operations too

9
UTM - xstate
10
UTM Hardware Modifications Performance

• Requires saving register state
• Doesn't provide explanation that works with
  context switches though
• Regular transactional memory implementation
• Was not benchmarked
• Performance similar to LTM because common case is
  still in hardware

11
VTM

• Like UTM/LTM, common case is fast hardware
  implementation
• Requires OS support
• Supports transactions up to virtual memory size
• Transactions can switch processors and survive
  multiple timeslices
• No nested transactions

12
VTM
13
VTM

• Memory state managed with XADT
• Transaction Address Data Table
• XADT holds overflowed speculative data, and
  access information
• When data is in cache, don't need to interact
  with XADT
• After overflow or on cache miss, need to check
  XADT for conflicts
• XF (Transaction Filter) is a performance
  enhancement

14
VTM - XADT
15
VTM

• Non-T accesses may mess with data
• If running, cache coherence alerts transactions
• If swapped out, VTM has to check state on resume
• On context switch, transaction data is forcibly
  flushed
• When a transaction is in the commit phase,
  non-transactional ops have to check XADT