Hybrid STM/HTM for Nested Transactions in Java Keith Chapman Tony - - PowerPoint PPT Presentation

Hybrid STM/HTM for Nested Transactions in Java

Keith Chapman Purdue U Tony Hosking ANU/Data61, Purdue U Eliot Moss UMass

Motivation

STM has been around for ages

• But STM is slow

Commodity hardware for transactions available now

• But HTM approaches are only best effort

Out goal: Accelerate STM with HTM when possible

Nested Transactions

Allow composition of transactions Two flavors

• Closed Nested Transactions
• HTM inside STM not useful; must do all the same work
• Open Nested Transactions
• HTM inside STM avoids most TM work – HTM well-suited!

XJ: Transactional Java

XJ Language

• Supports flat and closed/open/boosted nested transactions

The implementation supports hybrid transactions

• HTM support via Intel TSX
• HTM and STM can co-exist

Uses an Optimistic-reads / Pessimistic-writes protocol

TM Metadata

Txn Log

Version # Txn ID 1

One metadata word for every object

STM Transaction Protocol (Read)

T1 Log Check Mode T1 Read T1 Validate T1 Commit

T1 1 1

STM Transaction Protocol (Write)

T1 Log Check Mode T1 Write T1 Commit

STM Conflict Detection

T1 Log T2 Log T1 Read T2 Write T1 Validate T1 Abort

T2 1

Hybrid Transaction Protocol

STM – HTM conflicts detected by lock word accesses

• Explicit XABORT if locked by another transaction
• HTM reads – Read the metadata word
• STM writes modify the metadata word
• Causes HTM to abort
• HTM writes – Increment version number
• Causes STM read invalidation / HTM abort

Abstract Locking & Undo Operations

Abstract Locks for STM

Open / Boosted Atomic Method Body

Acquire abstract locks Release abstract locks

If top level transaction

Open / Boosted Atomic Method Body

Acquire abstract locks Log abstract locks

If nested transaction

Log undo operations

Abstract Locks for Hybrid TM

Open / Boosted Atomic Method Body

Validate abstract locks

Open / Boosted Atomic Method Body

Acquire abstract locks Log abstract locks

If top level is HTM

Log undo operations

Why Validation Works

• HTM vs STM
• If abstract locks conflict they must touch some same

physical words in the abstract locking data structure — otherwise they could not detect the conflict

• HTM vs HTM
• No conflict in the locking data structure because all

accesses to it are reads

• Any real conflicts that exist will occur on the actual

data structure

Open / Boosted Atomic Method Body

Validate abstract locks

STM and HTM Methods

STM needs logging HTM doesn't Different actions during read/write Different actions for abstract locks HTM should fall back to STM Maintain separate HTM and STM versions of methods

XJ System Architecture

HTM 4-5 times faster than STM

XJ source code XJ run-time library XJ Compiler standard Java bytecode XJ Rewriter bytecode + run-time calls HTM-enabled JVM

compile load run

JVM Modifications

Kept to a minimum Modifications done on OpenJDK:

• Native methods to begin, end, and abort a HW transaction
• Made them intrinsic to the HotSpot C1/C2 compilers

Had to go through several hoops to get HTM to work with HotSpot’s

• ptimizing compilers

Results

Synchrobench

Micro-benchmarks to evaluate synchronization performance on various data structures Added ability to run multiple operations within a single transaction (group size) Included XJ versions of the benchmarks

• TransactionalFriendlyTreeSet

48-way, Intel Xeon E5-2690 v3 machine with 2 sockets of 12 hyperthreaded cores

Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48

Open nested Closed nested

Group size 1

5% Updates

Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Group size 1 Group size 2

Open nested Closed nested 5% Updates

Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Group size 1 Group size 2 Group size 4

Open nested Closed nested 5% Updates

Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Group size 1 Group size 2 Group size 4 Group size 8

Open nested Closed nested 5% Updates

Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Group size 1 Group size 2 Group size 4 Group size 8 Group size 16

Open nested Closed nested 5% Updates

Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Throughput (Normalized) 0.2 0.4 0.6 0.8 1 Threads 1 2 4 8 12 16 20 24 28 32 36 40 44 48 Group size 1 Group size 2 Group size 4 Group size 8 Group size 16 Group size 32

Open nested Closed nested 5% Updates

50 100 150 200 1 2 4 8 12 16 20 24 28 32 36 40 44 48 1 2 4 8 12 16 20 24 28 32 36 40 44 48 1 2 4 8 12 16 20 24 28 32 36 40 44 48

Group size 1 Group size 2 Group size 4

committed ops and aborted txns (106)

• pen htm commits

closed htm commits

• pen stm commits

closed stm commits htm aborts

Conclusions

STM and HTM can co-exist for nested transactions in Java

• Closed nesting — Similar to previous schemes
• Open nesting — Novel validation mechanism
• Implemented in OpenJDK on Intel TSX — Artifact evaluated

When it works, HTM is ~4-5× faster than STM Open nesting increases the envelope of effectiveness for HTM Production VM would need deeper modification

• Hybrid STM/HTM for Nested Transactions on OpenJDK. OOPSLA’16

http://dx.doi.org/10.1145/2983990.2984029

• Extending OpenJDK to Support Hybrid STM/HTM. VMIL’16 http://

dx.doi.org/10.1145/2998415.2998417