Uniform Transactional Execution Environment for Java

1
Uniform Transactional Execution Environment for
Java

• Lukasz Ziarek
• Adam Welc, Suresh Jagannathan, Vijay Menon,
  Tatiana Shpeisman, and Ali-Reza Adl-Tabatabai

2
Motivation

• Much recent interest in transactions
• Simpler programming model
• Alternative to lock based synchronization
• Tool for extracting additional parallelism
• Improved performance and scalability
• Limitations prevent adoption of transactions
• Difficult to compose with other concurrency
  control primitives (locks and monitors)
• Fundamental difference in semantics (visibility
  of values)
• Difficult to communicate between transactions
• Difficult to utilize libraries and legacy code
• No direct support for I/O, threads

3
Thread 1 Thread 2 synchronized(n) synchronized
(o) synchronized(m) y 1
do synchronized(m) tmpA y
while(tmpA 0) synchronized(m) z1
do synchronized(m)
tmpB z while(tmpB 0)

atomic()
atomic()
atomic()
y
atomic()
y
atomic()
z
atomic()
z
4
Proposed Solution
void foo() atomic synchronized(o)

transactions
P-SLE
locks
AS
5
Pure Software Lock Elision (P-SLE)

• Motivation
• Use transactional machinery for uniformity and
  greater concurrency
• Retain visibility rules defined by locks
• Locked regions are treated as transactions
• Transparently replace synchronized with atomic
• Underlying TM implementation handles conflicts,
  contention, and ordering
• Choice of underlying STM is important
• Weak atomic STMs do not mirror lock semantics
• We want similar visibility guarantees to locks

6
Example - Publication
Initially data 42 ready false val 0
Thread1 Thread2 synchronized(m) tmp
data data 1 synchronized(m) ready
true if(ready) val tmp
Finally data 1 ready true val 1
7
Example - Publication
Initially data 42 ready false val 0
Thread1 Thread2 atomic() tmp
data data 1 atomic() ready true
if(ready) val tmp

• Strong Atomicity provides sufficient visibility
  guarantees

42
Finally data 1 ready true val 42
8
Why P-SLE is not enough?

• Explicit communication between critical sections
• Wait/Notify
• Implicit communication between critical sections
• Nested monitors, volatiles
• Irrevocable actions
• I/O, native methods, thread creation, etc

9
Example (P-SLE is not enough)
Thread 1 Thread 2 synchronized(m)
synchronized(o) o.wait()
synchronized(o)
o.notify()
10
Atomic Serialization/Fallback

• Motivation Some locks simply cannot be elided
• Communication, irrevocable actions
• Revert transactional execution to use locks
• Abort the transaction
• Acquire the original monitors
• What about user defined transactions?
• Acquire a compiler generated global lock

11
Model
Syntactic Transactions
Void foo() atomic synchronized(o)

AS
Generated Transactions
fallback
Locks
12
Detecting Visibility Violations

• Dynamically detect visibility violations
• Utilize the underlying STM
• Switch underlying execution engine from
  transactions to locks when necessary
• Visibility violation
• I/O, native method calls, etc.
• Monitor interactions between locked regions and
  transactional regions
• Extend the STM contention management to track
  monitor objects
• Acquire transactional locks on the monitor objects

13
Thread 1 Thread 2 synchronized(n) synchronized
(o) synchronized(m) y 1
do synchronized(m) tmpA y
while(tmpA 0) synchronized(m)
z1 do synchronized(m)
tmpB z while(tmpB 0)

atomic
r
r
atomic
W
W
r
atomic
W
W
atomic
W
atomic
atomic
14
Implementation

• Pervasive across entire software stack
  compiler, VM, runtime libraries
• Built on an optimistic updates in place STM with
  support for Strong Atomicity
• Can be supported by any STM implementation which
  adheres to Strong Atomicity
• Write buffering

15
Pure Software Lock Elision

• Translate Java critical sections into
  transactions
• Build stack based representation of monitor
  enter/exit calls
• Based on stack - generate primary/nested
  primitives
• Pass pointer to monitor object down through the
  software stack
• Special support for synchronized methods
• Add explicit transaction end on exception exit
  path
• No longer release monitors in the VM on exit path

16
Monitors

• Passed as pointers to the TM Library
• TM Library responsible for transaction/monitor
  interactions
• Transactions acquire read lock on monitor enter
• Allows concurrency with other transactions
• Lock based executions acquire write lock on
  monitor enter
• Locks released on exit of critical sections
• Requires separate lock set for monitor objects
• On fallback
• Upcall to the VM to acquire monitors

17
Benchmarks

• All our experiments were performed on an Intel
  Clovertown system with two 2.66 GHz quad-core
  processors and 3.25 GB of RAM.
• Benchmarks include TSP, 007, and SpecJBB
• Benchmark drivers and all classpath libraries
  were also executed
• Benchmarks perform file I/O, thread creation,
  wait/notify, joins, reflection, and class
  loading/initialization
• Correctly handle such situations by falling back
  to locks
• Able to achieve performance equivalent to
  underlying STM (PLDI 2006)

18
007 coarse grain locks
19
TSP mid grain locks
20
JBB fine grain locks
21
Related Work

• Welc et. al. (ECOOP 2006)
• Requires lock based programs to have the same
  visibility as transactions
• Requires programmers to determine correctness
  with respect to visibility
• Smaragdakis (OOPSLA 2007)
• Requires language extensions
• Relies on the programmer to define consistency at
  specific points within a transaction
• Lots of work on transactions!
• Too many to list

22
Contributions

• Mechanism to transparently execute Java
  synchronized sections transactionally (P-SLE)
• Concurrency model integrating (elided) locks and
  explicit transactional constructs (atomics)
• Design and implementation of a uniform execution
  environment supporting both primitives

23
Questions?