1. Log-based Transactional Memory
LogTM: Log-based Transactional Memory
11/24/2018
Log-based Transactional Memory
Mark D. Hill
Multifacet Project, Univ. of Wisconsin—Madison
April 13, Michigan (Go Blue!)
Multicore here: “Intel has 10 projects in the works that contain four or more computing cores per chip” —Intel CEO, Fall ’05
How program? “Blocking on a mutex is a surprisingly delicate dance” —OpenSolaris, mutex.c
UW-Madison Architecture Seminar

2. LogTM: Log-based Transactional Memory
11/24/2018
LogTM Contributors
Faculty
Mark Hill, Ben Liblit, Mike Swift, David Wood
Students
Jayaram Bobba, Derek Hower, Kevin Moore, Haris Volos, Luke Yen
Alumna
Michelle Moravan
Funding
Grants from U.S. National Science Foundation
Donations from Intel and Sun
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

3. Summary Our Transactional Memory (TM) goals
Unlimited TM model: even large/long transactions
Facilitate SW composition: unlimited nesting
Accelerate with some HW support
Log-based TM (Signature Edition)
Supports unlimited TM w/ nesting
Accelerates commit by writing new values in place (after saving old values in a per-thread log)
Signatures summarize read/write sets
HW mechanisms: simple, policy-free, SW accessible
11/24/2018
Wisconsin Multifacet Project

4. LogTM: Log-based Transactional Memory
11/24/2018
Outline
TM Motivation & Background
Why TM?, Terminlogy, & Taxonomy
LogTM Hardware Preview
LogTM Version Management
LogTM Conflict Detection
LogTM Evaluation
LogTM Operating System Interactions (optional)
Summary & Future Directions
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

5. LogTM: Log-based Transactional Memory
11/24/2018
Locks are Hard
// WITH LOCKS
void move(T s, T d, Obj key){
LOCK(s);
LOCK(d);
tmp = s.remove(key);
d.insert(key, tmp);
UNLOCK(d);
UNLOCK(s); }
Moreover
Coarse-grain locking limits concurrency
Fine-grain locking difficult
move(a, b, key1);
move(b, a, key2);
Thread 0
Thread 1
DEADLOCK!
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

6. Transactional Memory (TM)
LogTM: Log-based Transactional Memory
11/24/2018
Transactional Memory (TM)
void move(T s, T d, Obj key){
atomic {
tmp = s.remove(key);
d.insert(key, tmp); }
Programmer says
“I want this atomic”
TM system
“Makes it so”
Software TM (STM) Implementations
Currently slower than locks
Always slower than hardware?
Hardware TM (HTM) Implementations
Leverage cache coherence & speculation
Fast
But hardware finite & should be policy-free
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

7. Some Transaction Terminology
LogTM: Log-based Transactional Memory
11/24/2018
Some Transaction Terminology
Transaction: State transformation that is:
Atomic (all or nothing)
Consistent
Isolated (serializable)
Durable (permanent)
Commit: Transaction successfully completes
Abort: Transaction fails & must restore initial state
Read (Write) Set: Items read (written) by a transaction
Conflict: Two concurrent transactions conflict if either’s write set overlaps with the other’s read or write set
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

8. Nested Transactions for Software Composition
LogTM: Log-based Transactional Memory
11/24/2018
Nested Transactions for Software Composition
Modules expose interfaces, NOT implementations
Example
Insert() calls getID() from within a transaction
The getID() transaction is nested inside the insert() transaction
void insert(object o){
// parent TX
begin_transaction();
t.insert(getID(), o);
commit_transaction(); }
int getID() {
// child TX
begin_transaction(); id = global_id++;
commit_transaction();
return id; }
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

9. LogTM: Log-based Transactional Memory
11/24/2018
Closed Nesting
Child transactions remain isolated until parent commits
On Commit child transaction is merged with its parent
Flat
Nested transactions “flattened” into a single transaction
Only outermost begins/commits are meaningful
Any conflict aborts to outermost transaction
Partial rollback
Child transaction can be aborted independently
Can avoid costly re-execution of parent transaction
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

10. LogTM: Log-based Transactional Memory
11/24/2018
Implementing TM
Version Management
new values for commit
old values for abort
Must keep both
Conflict Detection
Find read-write, write-read or write-write conflicts among concurrent transactions
Allows multiple readers OR one writer
Large state
(must be precise)
Checked often
(must be fast)
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

11. How Do Hardware TM Systems Differ?
LogTM: Log-based Transactional Memory
11/24/2018
How Do Hardware TM Systems Differ?
Version Management
Lazy: buffer updates & move on commit
Eager: update “in place”
after saving old values
Conflict Detection
Lazy: check on commit
Eager: check before read/write
Like Databases with Optimistic Conc. Ctrl.
No HTMs (yet)
Stanford TCC
Illinois Bulk
Herlihy/Moss TM
MIT LTM
Intel/Brown VTM
Like Databases with Conservative C. Ctrl.
MIT UTM
Wisconsin LogTM
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

12. Transactional Memory Goals/Challenges
LogTM: Log-based Transactional Memory
11/24/2018
Transactional Memory Goals/Challenges
Unlimited TM Model
Large transactions: cache victimization & even paging
Long transactions: thread switching/mitgration
OS traps/calls?
Facilitate SW composition
Unlimited closed nesting (open nesting?)
Accelerate with at most modest HW support
Make the common case fast
Make HW simple, policy-free, & SW exposed
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

13. LogTM: Log-based Transactional Memory
11/24/2018
Outline
TM Motivation & Background
LogTM Hardware Preview
LogTM Version Management
LogTM Conflict Detection
LogTM Evaluation
LogTM Operating System Interactions (optional)
Summary & Future Directions
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

14. Single-CMP/Multicore System
LogTM: Log-based Transactional Memory
11/24/2018
Single-CMP/Multicore System
L1 $
Core0
L1$
Core2
L1$
Core13
L1$
Core14
L1$
Core15 …
Interconnect
L2 $
DRAM
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

15. LogTM Per-Core Hardware
LogTM: Log-based Transactional Memory
11/24/2018
LogTM Per-Core Hardware
Registers
Register Checkpoint
Conflict Detection:
 Signatures
Version Mgmt: Pointers to Segmented Log 
TMCount
Read
Write
LogFrame
SummaryRead
LogPtr
SummaryWrite
Processor (SMT Context)
No Explicit TM State 
Tag Data
Data Caches
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

16. LogTM: Log-based Transactional Memory
11/24/2018
Outline
Motivation & Background
LogTM Hardware Preview
LogTM Version Management
Basic Logging & Segmented Logs for Nesting
LogTM Conflict Detection
LogTM Evaluation
LogTM Operating System Interactions (optional)
Summary & Future Directions
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

17. LogTM’s Eager Version Management
LogTM: Log-based Transactional Memory
11/24/2018
LogTM’s Eager Version Management
New values stored in place
Old values stored in transaction log
Allocated per-thread in virtual memory (like per-thread stacks)
Filled by hardware (during transactions)
Read by software (on abort) VA
Memory Block
R W Sets 00 1 40 C0
1000 c0 --
Log Base
1000
1040
Transaction Log
--23 40
Log Ptr
1090
1080
TM count 1
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

18. Segmented Transaction Log for Nesting
LogTM: Log-based Transactional Memory
11/24/2018
Segmented Transaction Log for Nesting
LogTM’s log is a stack of frames (like activation records)
A frame contains:
Header (including saved registers and pointer to parent’s frame)
Undo records (block address, old value pairs)
Garbage headers (headers of committed closed transactions)
Commit action records
Compensating action records
Header
LogFrame
Undo record
LogPtr
Undo record
TM count 2 1
Header
Undo record
Undo record
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

19. LogTM: Log-based Transactional Memory
11/24/2018
Closed Nested Commit
Merge child’s log frame with parent’s
Mark child’s header as “dummy header”
Copy pointer from child’s header to LogFrame
Header
LogFrame
Undo record
LogPtr
Undo record
TM count 2 1
Header
Undo record
Undo record
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

20. LogTM Version Management Discussion
LogTM: Log-based Transactional Memory
11/24/2018
LogTM Version Management Discussion
Eager Version Management via Segment Log
Advantages:
Transaction read new values normally (w/o bypassing)
No data movement at commit
Both old & new data in (virtual) memory
Both old & new data can be cached or victimized
Supports unbounded nesting
No extra indirection (unlike STM)
Disadvantages
Aborts slower & handled by software
Adds HW to write log
Requires eager conflict detection?
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

21. LogTM: Log-based Transactional Memory
11/24/2018
Outline
TM Motivation & Background
LogTM Hardware Preview
LogTM Version Management
LogTM Conflict Detection
Signatures, Nesting, & Detection via Coherence
LogTM Evaluation
LogTM Operating System Interactions (optional)
Summary & Future Directions
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

22. LogTM-SE Read/Write Set Summary
LogTM: Log-based Transactional Memory
11/24/2018
LogTM-SE Read/Write Set Summary
Use Per-Thread Signatures (adapted from Bulk)
(Original LogTM used in-cache read/write bits)
External ST E
External ST F A B D C
Program:
xbegin
LD A
ST B
LD C
LD D
ST C …
FALSE POSITIVE:
CONFLICT!
Hash Function(s)
NO CONFLICT
ALIAS R W
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

23. Conflict Detection for Unbounded Nesting
LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
10/25/06
11/24/2018
Conflict Detection for Unbounded Nesting
Nesting Affects Signatures (not coherence next)
Nested Begin: Save R/W Signatures on Log
Partial Abort: Restore R/W Signatures
(Closed) Nested Commit: Discard Saved Signatures
Open Nesting also handled
Recall LogTM’s Segmented Log already supports version management for unbounded nesting
Add saved signature space to frame header
<Skip Nested Signature Example>
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 24

24. LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
10/25/06
11/24/2018
Nested Begin
Program
Processor State
Transaction Log
xbegin
LD …
ST … R W
Xact header
Undo entry
Undo entry
TMCount 1
Undo entry
Log Frame
Xact header
Log Ptr
11/24/2018
Wisconsin Multifacet Project
© 2007 Mulitfacet Project
UW-Madison Architecture Seminar 25

25. LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
LogTM: Log-based Transactional Memory
10/25/06
11/24/2018
Nested Begin
Program
Processor State
Transaction Log
xbegin
LD …
ST … R W
Xact header
Undo entry
Undo entry
TMCount 2
Undo entry
Log Frame
Xact header
Log Ptr
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 26

26. LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
LogTM: Log-based Transactional Memory
11/24/2018
10/25/06
Partial Abort
Program
Processor State
Transaction Log
xbegin
LD …
ST …
ABORT! R W
Xact header
Undo entry
Undo entry
TMCount 2 1
Undo entry
Log Frame
Xact header
Log Ptr
Undo entry
Undo entry
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 27

27. LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
LogTM: Log-based Transactional Memory
11/24/2018
10/25/06
Nested Commit
Program
Processor State
Transaction Log
xbegin
LD …
ST …
xend R W
Xact header
Undo entry
Undo entry
TMCount 1 2
Undo entry
Log Frame
Xact header
Garbage Hdr
Log Ptr
Undo entry
Undo entry
11/24/2018
Wisconsin Multifacet Project
© 2007 Mulitfacet Project
UW-Madison Architecture Seminar 28

28. Unbounded Nesting Support Summary
LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
10/25/06
11/24/2018
Unbounded Nesting Support Summary
Closed nesting:
Begin: save signatures
Abort: restore signatures
Commit: No signature action
Open nesting:
Commit: restore signatures
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 29

29. LogTM’s Eager Conflict Detection (before access)
LogTM: Log-based Transactional Memory
11/24/2018
LogTM’s Eager Conflict Detection (before access)
LogTM detects conflicts using coherence
Requesting core issues coherence request
L2 directory forwards to other core(s)
Responding core
Detects conflict using local signatures
Informs requesting processor of conflict
(4) Requesting core resolves conflict
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

30. Protocol Animation: Transactional Write
LogTM: Log-based Transactional Memory
11/24/2018
Protocol Animation: Transactional Write
Core C0 store
C0 sends get exclusive (GETX) request
L2 Directory responds with data (old)
C0 executes store
L2 Directory
GETX
I [old]
[old]
DATA C0 C1
TM mode 1
TM mode
Signature
(--)
(--)
(W-)
Signature
(--)
M [new]
M [old]
I [none]
I [none]
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

31. Protocol Animation: Transactional Conflict
LogTM: Log-based Transactional Memory
11/24/2018
Protocol Animation: Transactional Conflict
In-cache transaction conflict
C1 sends get shared (GETS) request
L2 Directory forwards to P0
C1 detects conflict and sends NACK
L2 Directory
[old]
GETS
Fwd_GETS C0 C1
TM mode 1
TM mode
Signature
(W-)
Signature
(--)
M [new]
M [new]
I [none]
Conflict!
NACK
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

32. Cache Victimization Gracefully Handled!
Consider eviction of transactional data from Core C0
No Effect on R/W Set Summary via Signatures
For Conflict Detection, Forward Coherence Requests After Victimization
Trivial with broadcast coherence
Silent S replacements w/ directory: C0  C0
Writeback to directory sticky: C0  C0
Recall Eager Version Management via Log
On commit: no need to re-fetch victimized block
On abort: SW log walk naturally re-fetches victimized block
11/24/2018
Wisconsin Multifacet Project

33. Sticky States: No New Bits in L1 Cache or L2 Directory
Shared (L2) Directory State M S I E
“Sticky-M”
“Sticky-S”
Private (L1) Cache State
11/24/2018
Wisconsin Multifacet Project

34. LogTM: Log-based Transactional Memory
11/24/2018
Conflict Resolution
Conflict Resolution
Can wait risking deadlock or abort risking livelock
Wait/abort transaction at requesting or responding proc?
LogTM resolves conflicts at requesting processor
Original LogTM included HW timestamps
Requesting processor can waits (using nacks/retries)
or aborts if other processor is waiting (deadlock possible) & it is logically younger
Current LogTM has requesting processor traps to software contention manager that decides who waits/aborts
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

35. LogTM Conflict Detection Discussion
LogTM: Log-based Transactional Memory
11/24/2018
LogTM Conflict Detection Discussion
Eager Conflict Detection via Signatures & Coherence
Advantages:
Supports unbounded nesting
Signatures are compact HW
Signatures software-accessible: save/restore for nesting
Coherence provide efficient conflict detection
Disadvantages
Signatures have false positives
Requires modest coherence protocol changes
Does not (yet) handle thread migration & paging (but coming later)
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

36. LogTM: Log-based Transactional Memory
11/24/2018
Outline
TM Motivation & Background
LogTM Hardware Preview
LogTM Version Management
LogTM Conflict Detection
LogTM Evaluation
Methods, vs. Lock, & vs. Perfect Signatures
LogTM Operating System Interactions (optional)
Summary & Future Directions
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

37. Single-CMP LogTM System
LogTM: Log-based Transactional Memory
11/24/2018
Single-CMP LogTM System
L1 $
Core0
L1$
Core1
Core13
Core14
Core15 …
L2 $
DRAM
Interconnect
Core 15
(SMT Context 0)
Registers
Register Checkpoint
LogPtr
TMCount
Read
Write
LogFrame
SummaryRead
SummaryWrite
2-way
(SMT Context 1)
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

38. Experimental Methodology
Infrastructure
Virtutech Simics full-system simulation
Wisconsin GEMS timing modules
System
32 transactional threads (16 cores x 2 SMT threads/core)
32kB 4-way L1 I and D, 64-byte blocks, 1cycle latency
8MB 8-way unified L2, 34 cycle latency
L2 directory for coherence, maintains full sharer bit vector
Workloads
Radiosity, Raytrace, Mp3d, Cholesky Berkeley DB
11/24/2018
Wisconsin Multifacet Project

39. Lock Results
11/24/2018
Wisconsin Multifacet Project

40. Perfect Signature Results
Perfect signatures similar or better than Locks
11/24/2018
Wisconsin Multifacet Project

41. Realistic Signature Results
Realistic Signatures similar to Perfect Signatures and Locks
For our workloads, false positives are not a problem
11/24/2018
Wisconsin Multifacet Project

42. What about scalability?
Bigger system
Bigger transactions
False positives are a function of:
Transaction size
Transactional duty cycle
Number of concurrent transactional threads
Filtering due to on-chip directory protocol
Signatures gracefully degrade to serialization
11/24/2018
Wisconsin Multifacet Project

43. LogTM Evaluation Discussion
LogTM: Log-based Transactional Memory
11/24/2018
LogTM Evaluation Discussion
LogTM Running Splash & BerkeleyDB
Good News:
Works!
Performs similar to locks
Signature false postive not (yet) an issues
Bad News
Baby workloads
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

44. LogTM: Log-based Transactional Memory
11/24/2018
Outline
TM Motivation & Background
LogTM Hardware Preview
LogTM Version Management
LogTM Conflict Detection
LogTM Evaluation
LogTM Operating System Interactions (optional)
Escape Actions, Thread Switching, (& Paging)
Summary & Future Directions
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

45. LogTM: Log-based Transactional Memory
11/24/2018
Escape Actions
Allow non-transactional escapes from a transaction
(e.g., system calls, I/O)
Similar to Zilles’s pause/unpause
Escape actions never:
Abort
Stall
Cause other transactions to abort
Cause other transactions to stall
Commit and compensating actions
similar to open nests
Not recommended for the average programmer!
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

46. Thread Switching Support
LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
10/25/06
11/24/2018
Thread Switching Support
Why?
Support long-running transactions
What?
Conflict Detection for descheduled transactions
How?
Summary Read / Write Signatures w/ Invariant:
If thread t of process P is scheduled to use an active signature, the corresponding summary signature holds the union of the saved signatures from all descheduled threads from process P.
Updated using TLB-shootdown-like mechanism <skip example>
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 49

47. Handling Thread Switching
LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
10/25/06
11/24/2018
Handling Thread Switching
Summary W R
Summary W R
Summary W R
Summary W R OS T2 T3 T1 W
Summary R W W W W R R R R P1 P2 P3 P4
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 50

48. Handling Thread Switching
LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
10/25/06
11/24/2018
Handling Thread Switching W OS
Summary R
Deschedule T2 T3 T1
Summary W R
Summary W R
Summary W R W
Summary R W W W W R R R R P1 P2 P3 P4
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 51

49. Handling Thread Switching
LogTM-SE: Log-based Transactional Memory: Signature Edition
LogTM: Log-based Transactional Memory
10/25/06
11/24/2018
Handling Thread Switching W
Summary W R
Summary W R OS
Summary R
Deschedule T2 T3 T1
Summary W R
Summary W R
Summary W R W
Summary R W W W W R R R R P1 P2 P3 P4
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 52

50. Handling Thread Switching
LogTM-SE: Log-based Transactional Memory: Signature Edition
LogTM: Log-based Transactional Memory
10/25/06
11/24/2018
Handling Thread Switching W OS
Summary R T1 T2 T3 W
Summary W R
Summary W R W
Summary R
Summary R W W W W R R R R P1 P2 P3 P4
11/24/2018
Wisconsin Multifacet Project
© 2007 Mulitfacet Project
UW-Madison Architecture Seminar 53

51. Thread Switching Support Summary
LogTM-SE: Log-based Transactional Memory: Signature Edition
LogTM: Log-based Transactional Memory
10/25/06
11/24/2018
Thread Switching Support Summary
Summary Read / Write signatures
Summarizes descheduled threads with active transactions
One OS structure per process
Check summary signature on every memory access
Updated on transaction deschedule
Similar to TLB shootdown
Coherence
11/24/2018
Wisconsin Multifacet Project
© 2007 Mulitfacet Project
UW-Madison Architecture Seminar 54

52. Paging Support Summary
LogTM: Log-based Transactional Memory
LogTM-SE: Log-based Transactional Memory: Signature Edition
10/25/06
11/24/2018
Paging Support Summary
Problem:
Changing page frames
Need to maintain isolation on transactional blocks
Solution:
On Page-Out:
Save Virtual -> Physical mapping
On Page-In:
If different page frame, update signatures with physical address of transactional blocks in new page frame.
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar
© 2007 Mulitfacet Project 55

53. LogTM OS Interaction Discussion
LogTM: Log-based Transactional Memory
11/24/2018
LogTM OS Interaction Discussion
OS Call/Traps via Escape Actions, Thread Migration via Summary Signatures, & Crude Paging Support
Advantages:
Summary Signatures are compact, software-accessible HW
Most complexity for rare events religated to SW
Coherence not used/modfied for rare events (e.g., conflict detection after thread migration)
Disadvantages
Summary Signatures have false positives
TLB-shootdown-like unscalable SE
Paging support still crude
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

54. Summary Our Transactional Memory (TM) goals
Unlimited TM model: even large/long transactions
Facilitate SW composition: unlimited nesting
Accelerate with some HW support
Log-based TM (Signature Edition)
Supports unlimited TM w/ nesting
Accelerates commit by writing new values in place (after saving old values in a per-thread log)
Signatures summarize read/write sets
HW mechanisms: simple, policy-free, SW accessible
11/24/2018
Wisconsin Multifacet Project

55. Improving Transactional Memory
Non-Transactional Events
I/O & system calls
Development tools for TM
Profiling transaction conflicts
Detecting & preventing false sharing
What is the right interface for TM?
ISA changes will outlast implementations
11/24/2018
Wisconsin Multifacet Project

56. Deconstructing Transactional Memory
LogTM: Log-based Transactional Memory
11/24/2018
Deconstructing Transactional Memory
Hardware should provide primitives not solutions
TM is a programming language solution
Instead let hardware provide:
Checkpointing (version management)
Address Matching (conflict detection)
Software can build transactional memory
Other uses for these primitives
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

57. LogTM: Log-based Transactional Memory
11/24/2018
[HPCA 2006] LogTM: Log-based Transactional Memory
[ASPLOS 2006] Supporting Nested Transactional Memory in LogTM
[HPCA 2007] LogTM-SE: Decoupling Hardware Transactional Memory from Caches
[ISCA 2007] Performance Pathologies in Hardware Transactional Memory
FriendlyFire, StarvingWriter, SerializedCommit, Futile-Stall, StarvingElder, RestartConvoy, & DuelingUpgrades
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

58. Google “Wisconsin GEMS”
Works w/ Simics (free to academics)  commercial OS/apps
SPARC out-of-order, x86 in-order, CMPs, SMPs, & LogTM
GPL release of GEMS used in seven non-Multifacet papers
Detailed
Processor
Model
Opal
Simics
Microbenchmarks
Random
Tester
Deterministic
Contended locks
Trace flie
11/24/2018
Wisconsin Multifacet Project

59. LogTM: Log-based Transactional Memory
11/24/2018
BACKUP SLIDES
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

60. HTM Virtualization Mechanisms
Before Virtualization
After Virtualization
$Miss
Commit
Abort
$Eviction
Paging
Thread Switch
UTM - H HC
VTM S SC
SWV
UnrestrictedTM A B AS
XTM
XTM-g
ASC
SCV
PTM-Copy
PTM-Select
LogTM-SE
Shaded = virtualization event
- = handled in simple HW
H = complex hardware
S = handled in software
A = abort transaction
C = copy values
W = walk cache
V = validate read set
B = block other transactions
LogTM-SE
11/24/2018 64
Wisconsin Multifacet Project
Wisconsin Multifacet Project

61. LogTM: Log-based Transactional Memory
11/24/2018
LogTM Overview
Hardware Transactional Memory promising
But, most HTMs require a slow, complex virtualization scheme to handle cache overflow, thread switch etc.
New LogTM: Log-based Transactional Memory
Virtualization “Built-In”
Policy-Free Hardware
Simple hardware primitives
Software-accessible state
Supports Transactions with:
Large memory footprints
Thread switching
Unbounded nesting
Paging
Apply this strategy to TM.
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

62. LogTM: Log-based Transactional Memory
11/24/2018
Paging Support
Why?
Support Large Transactions.
What?
Physical Relocation of Virtual Pages
How?
Update Signatures on paging activity
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar

63. LogTM: Log-based Transactional Memory
11/24/2018
Updating Signatures
Suppose:
Virtual Page (VP) 0x > Physical Frame(PP) 0x1000
Signature A:
{0x1040,0x1080, 0x30c0}
At Page Out:
Remember 0x40000->0x1000
At Page In:
Suppose 0x40000->0x2000
Signature A:
{0x1040,0x1080, 0x2040, 0x2080,0x30c0}
11/24/2018
Wisconsin Multifacet Project
UW-Madison Architecture Seminar