The Transactional Memory Garbage Collection Analogy Dan Grossman

The Transactional Memory / Garbage Collection Analogy Dan Grossman University of Washington OOPSLA 2007 24 October 2007 Dan Grossman: The TM/GC Analogy

Why are you here? Transactional Memory / Garbage Collection Analogy • How an analogy produces new research – A foundation of cognition? – A way to educate? Probably not why you’re here… But hope to encourage analogies as a key intellectual tool for practical results 24 October 2007 Dan Grossman: The TM/GC Analogy 2

Why are you here? Transactional Memory / Garbage Collection Analogy • Why GC is great – Benefits, limitations, implementation techniques Probably not why you’re here… But hope to give a new perspective on this mature topic 24 October 2007 Dan Grossman: The TM/GC Analogy 3

Why are you here? Transactional Memory / Garbage Collection Analogy • Why TM is great – Benefits, limitations, implementation techniques Probably is why you’re here… A very hot topic I hope to put in context – Promote without overselling 24 October 2007 Dan Grossman: The TM/GC Analogy 4

Why am I here? Transactional Memory / Garbage Collection Analogy • Understand TM and GC better by explaining remarkable similarities – Benefits, limitations, and implementations “TM is to shared-memory concurrency as GC is to memory management” 24 October 2007 Dan Grossman: The TM/GC Analogy 5

How to do it • Why an analogy helps • Brief separate overview of GC and TM • The core technical analogy (but read the essay) – And why concurrency is still harder • Provocative questions based on the analogy (about 40 minutes; plenty of time for discussion) 24 October 2007 Dan Grossman: The TM/GC Analogy 6

Two bags of concepts reachability dangling pointers reference counting liveness analysis weak pointers space exhaustion real-time guarantees finalization conservative collection races eager update escape analysis false sharing memory conflicts deadlock open nesting obstruction-freedom GC 24 October 2007 TM Dan Grossman: The TM/GC Analogy 7

Interbag connections reachability dangling pointers liveness analysis reference counting weak pointers space exhaustion real-time guarantees finalization conservative collection races eager update escape analysis false sharing memory conflicts deadlock open nesting obstruction-freedom GC 24 October 2007 TM Dan Grossman: The TM/GC Analogy 8

Analogies help organize dangling pointers space exhaustion reachability conservative collection weak pointers reference counting liveness analysis real-time guarantees finalization races deadlock memory conflicts false sharing open nesting eager update escape analysis obstruction-freedom GC 24 October 2007 TM Dan Grossman: The TM/GC Analogy 9

So the goals are… • Leverage the design trade-offs of GC to guide TM – And vice-versa? • Identify open research • Motivate TM – TM improves concurrency as GC improves memory – GC is a huge help despite its imperfections – So TM is a huge help despite its imperfections 24 October 2007 Dan Grossman: The TM/GC Analogy 10

How to do it “TM is to shared-memory concurrency as GC is to memory management” • Why an analogy helps • Brief separate overview of GC and TM • The core technical analogy (but read the essay) – And why concurrency is still harder • Provocative questions based on the analogy 24 October 2007 Dan Grossman: The TM/GC Analogy 11

Memory management Allocate objects in the heap Deallocate objects to reuse heap space – If too soon, dangling-pointer dereferences – If too late, poor performance / space exhaustion 24 October 2007 Dan Grossman: The TM/GC Analogy 12

GC Basics Automate deallocation via reachability approximation – Approximation can be terrible in theory roots heap objects • Reachability via tracing or reference-counting – Duals [Bacon et al OOPSLA 04] • Lots of bit-level tricks for simple ideas – And high-level ideas like a nursery for new objects 24 October 2007 Dan Grossman: The TM/GC Analogy 13

A few GC issues • Weak pointers – Let programmers overcome reachability approx. • Accurate vs. conservative – Conservative can be unusable (only) in theory • Real-time guarantees for responsiveness 24 October 2007 Dan Grossman: The TM/GC Analogy 14

GC Bottom-line Established technology with widely accepted benefits Even though it can perform terribly in theory Even though you can’t always ignore how GC works (at a high-level) Even though an active research area after 40 years 24 October 2007 Dan Grossman: The TM/GC Analogy 15

Concurrency Restrict attention to explicit threads communicating via shared memory Synchronization mechanisms coordinate access to shared memory – Bad synchronization can lead to races or a lack of parallelism (even deadlock) 24 October 2007 Dan Grossman: The TM/GC Analogy 16

Atomic An easier-to-use and harder-to-implement primitive void deposit(int x){ synchronized(this){ int tmp = balance; tmp += x; balance = tmp; }} void deposit(int x){ atomic { int tmp = balance; tmp += x; balance = tmp; }} lock acquire/release (behave as if) no interleaved computation; no unfair starvation 24 October 2007 Dan Grossman: The TM/GC Analogy 17

TM basics atomic (and related constructs) implemented via transactional memory • Preserve parallelism as long as no memory conflicts – Can lead to unnecessary loss of parallelism • If conflict detected, abort and retry • Lots of complicated details – All updates must appear to happen at once 24 October 2007 Dan Grossman: The TM/GC Analogy 18

A few TM issues • Open nesting: atomic { … open { s; } … } • Granularity (potential false conflicts) atomic{… x. f++; …} atomic{… x. g++; … } • Update-on-commit vs. update-in-place • Obstruction-freedom • … 24 October 2007 Dan Grossman: The TM/GC Analogy 19

Advantages So atomic “sure feels better than locks” But the crisp reasons I’ve seen are all (great) examples – Personal favorite from Flanagan et al • Same issue as Java’s String. Buffer. append – (see essay for close 2 nds) 24 October 2007 Dan Grossman: The TM/GC Analogy 20

Code evolution void deposit(…) { synchronized(this) { … }} void withdraw(…) { synchronized(this) { … }} int balance(…) { synchronized(this) { … }} 24 October 2007 Dan Grossman: The TM/GC Analogy 21

Code evolution void int void deposit(…) { withdraw(…) { balance(…) { transfer(Acct synchronized(this) { … }} from, int amt) { if(from. balance()>=amt && amt < max. Xfer) { from. withdraw(amt); this. deposit(amt); } } 24 October 2007 Dan Grossman: The TM/GC Analogy 22

Code evolution void deposit(…) { synchronized(this) { … }} void withdraw(…) { synchronized(this) { … }} int balance(…) { synchronized(this) { … }} void transfer(Acct from, int amt) { synchronized(this) { //race if(from. balance()>=amt && amt < max. Xfer) { from. withdraw(amt); this. deposit(amt); } } } 24 October 2007 Dan Grossman: The TM/GC Analogy 23

Code evolution void deposit(…) { synchronized(this) { … }} void withdraw(…) { synchronized(this) { … }} int balance(…) { synchronized(this) { … }} void transfer(Acct from, int amt) { synchronized(this) { synchronized(from) { //deadlock (still) if(from. balance()>=amt && amt < max. Xfer) { from. withdraw(amt); this. deposit(amt); } }} } 24 October 2007 Dan Grossman: The TM/GC Analogy 24

Code evolution void deposit(…) { atomic { … }} void withdraw(…) { atomic { … }} int balance(…) { atomic { … }} 24 October 2007 Dan Grossman: The TM/GC Analogy 25

Code evolution void int void deposit(…) { withdraw(…) { balance(…) { transfer(Acct atomic { … }} from, int amt) { //race if(from. balance()>=amt && amt < max. Xfer) { from. withdraw(amt); this. deposit(amt); } } 24 October 2007 Dan Grossman: The TM/GC Analogy 26

Code evolution void deposit(…) { atomic { … }} void withdraw(…) { atomic { … }} int balance(…) { atomic { … }} void transfer(Acct from, int amt) { atomic { //correct and parallelism-preserving! if(from. balance()>=amt && amt < max. Xfer){ from. withdraw(amt); this. deposit(amt); } } } 24 October 2007 Dan Grossman: The TM/GC Analogy 27

But can we generalize So TM sure looks appealing… But what is the essence of the benefit? You know my answer… 24 October 2007 Dan Grossman: The TM/GC Analogy 28

How to do it “TM is to shared-memory concurrency as GC is to memory management” • Why an analogy helps • Brief separate overview of GC and TM • The core technical analogy (but read the essay) – And why concurrency is still harder • Provocative questions based on the analogy 24 October 2007 Dan Grossman: The TM/GC Analogy 29

The problem, part 1 concurrent programming Why memory management is hard: race conditions Balance correctness (avoid dangling pointers) loss of parallelism deadlock And performance (no space waste or exhaustion) Manual approaches require whole-program protocols lock Example: Manual reference count for each object lock acquisition • Must avoid garbage cycles 24 October 2007 Dan Grossman: The TM/GC Analogy 30

The problem, part 2 synchronization Manual memory-management is non-modular: • Caller and callee must know what each other access or deallocate to ensure right memory is live locks are held release • A small change can require wide-scale changes to code – Correctness requires knowing what data subsequent computation will access concurrent 24 October 2007 Dan Grossman: The TM/GC Analogy 31

The solution Move whole-program protocol to language implementation • One-size-fits-most implemented by experts – Usually combination of compiler and run-time TM • GC system uses subtle invariants, e. g. : – Object header-word bits thread-shared thread-local – No unknown mature pointers to nursery objects optimistic concurrency • In theory, object relocation can improve performance by increasing spatial locality parallelism – In practice, some performance loss worth convenience 24 October 2007 Dan Grossman: The TM/GC Analogy 32

Two basic approaches update-on-commit conflict-free conflicts • Tracing: assume all data is live, detect garbage later update-in-place conflicts • Reference-counting: can detect garbage immediately conflict-detection – Often defer some counting to trade immediacy for performance (e. g. , trace the stack) optimistic reads 24 October 2007 Dan Grossman: The TM/GC Analogy 33

So far… correctness performance automation new objects eager approach lazy approach 24 October 2007 memory management dangling pointers space exhaustion garbage collection nursery data reference-counting tracing Dan Grossman: The TM/GC Analogy concurrency races deadlock transactional memory thread-local data update-in-place update-on-commit 34

Incomplete solution GC a bad idea when “reachable” is a bad approximation of “cannot-be-deallocated” Weak pointers overcome this fundamental limitation – Best used by experts for well-recognized idioms (e. g. , software caches) In extreme, programmers can encode manual memory management on top of GC – Destroys most of GC’s advantages… 24 October 2007 Dan Grossman: The TM/GC Analogy 35

Circumventing GC class Allocator { private Some. Object. Type[] buf = …; private boolean[] avail = …; } Allocator() { /*initialize arrays*/ } Some. Ojbect. Type malloc() { /* find available index */ } void free(Some. Object. Type o) { /* set corresponding index available */ } 24 October 2007 Dan Grossman: The TM/GC Analogy 36

Incomplete solution memory conflict TM GC a bad idea when “reachable” is a bad approximation of “cannot-be-deallocated” run-in-parallel Open nested txns Weak pointers overcome this fundamental limitation – Best used by experts for well-recognized idioms (e. g. , software caches) unique id generation In extreme, programmers can encode locking TM manual memory management on top of GC TM – Destroys most of GC’s advantages… 24 October 2007 Dan Grossman: The TM/GC Analogy 37

Circumventing GC TM class Spin. Lock { private boolean b = false; } void acquire() { while(true) atomic { if(b) continue; b = true; return; } } void release() { atomic { b = false; } } 24 October 2007 Dan Grossman: The TM/GC Analogy 38

Programmer control (some) TM For performance and simplicity, GC treats entire objects as reachable, which can lead to more space accessed less parallelism Parallelism Space-conscious programmers can reorganize data accordingly coarser granularity (e. g. , cache lines) But with conservative collection, programmers cannot completely control what appears reachable conflicting – Arbitrarily bad in theory 24 October 2007 Dan Grossman: The TM/GC Analogy 39

So far… memory management correctness dangling pointers performance space exhaustion automation garbage collection new objects nursery data eager approach reference-counting lazy approach tracing key approximation reachability manual circumvention weak pointers uncontrollable approx. conservative collection 24 October 2007 Dan Grossman: The TM/GC Analogy concurrency races deadlock transactional memory thread-local data update-in-place update-on-commit memory conflicts open nesting false memory conflicts 40

More in transactions • I/O: input after output of pointers can cause incorrect behavior due to dangling pointers irreversible actions Obstruction-freedom • Real-time guarantees doable but costly • Static analysis can avoid overhead escape potential conflicts – Example: liveness analysis for fewer root locations thread-local – Example: remove write-barriers on nursery data 24 October 2007 Dan Grossman: The TM/GC Analogy 41

Too much coincidence! memory management correctness dangling pointers performance space exhaustion automation garbage collection new objects nursery data eager approach reference-counting lazy approach tracing key approximation reachability manual circumvention weak pointers uncontrollable approx. conservative collection more… I/O of pointers real-time liveness analysis … 24 October 2007 Dan Grossman: The TM/GC Analogy concurrency races deadlock transactional memory thread-local data update-in-place update-on-commit memory conflicts open nesting false memory conflicts I/O in transactions obstruction-free escape analysis … 42

How to do it “TM is to shared-memory concurrency as GC is to memory management” • Why an analogy helps • Brief separate overview of GC and TM • The core technical analogy (but read the essay) – And why concurrency is still harder • Provocative questions based on the analogy 24 October 2007 Dan Grossman: The TM/GC Analogy 43

Concurrency is hard! I never said the analogy means TM parallel programming is as easy as GC sequential programming By moving low-level protocols to the language run-time, TM lets programmers just declare where critical sections should be But that is still very hard and – by definition – unnecessary in sequential programming Huge step forward 24 October 2007 =/ panacea Dan Grossman: The TM/GC Analogy 44

Stirring things up I can defend the technical analogy on solid ground Then push things (perhaps) too far … 1. Many used to think GC was too slow without hardware 2. Many used to think GC was “about to take over” (decades before it did) 3. Many used to think we needed a “back door” for when GC was too approximate 24 October 2007 Dan Grossman: The TM/GC Analogy 45

Inciting you Push the analogy further or discredit it • Generational GC? • Contention management? • Inspire new language design and implementation Teach programming with TM as we teach programming with GC Find other analogies and write essays 24 October 2007 Dan Grossman: The TM/GC Analogy 46

“TM is to shared-memory concurrency as GC is to memory management” 24 October 2007 Dan Grossman: The TM/GC Analogy 47