Compiler and runtime techniques for software transactional memory optimization

Wu, Peng; Michael, Maged M.; Praun, Christoph von; Nakaike, Takuya; Bordawekar, Rajesh; Cain, Harold W.; Caşcaval, Călin; Chatterjee, Siddhartha; Chiras, Stefanie; Hou, Rui; Mergen, Mark; Shen, Xiaowei; Spear, Michael; Wang, Hua Yong; Wang, Kun

doi:10.1002/cpe.1336

Cited by 21 publications

(19 citation statements)

References 39 publications

(36 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…When a transaction writes to a stack location or privately allocated memory that has not yet escaped the thread (i.e., a memory location that is not yet visible to other threads), the write does not induce any conflict. These contentionfree writes do not require write-barriers, but may need to be memory checkpointed if the system must recover the overwritten values upon a retry [9].…”

Section: Introductionmentioning

confidence: 99%

A Case for Including Transactions in OpenMP

Wong

Bihari

Supinski

et al. 2010

Beyond Loop Level Parallelism in OpenMP: Accelerators, Tasking and More

Self Cite

View full text Add to dashboard Cite

Abstract. Transactional Memory (TM) has received significant attention recently as a mechanism to reduce the complexity of shared memory programming. We explore the potential of TM to improve OpenMP applications. We combine a software TM (STM) system to support transactions with an OpenMP implementation to start thread teams and provide task and loop-level parallelization. We apply this system to two application scenarios that reflect realistic TM use cases. Our results with this system demonstrate that even with the relatively high overheads of STM, transactions can outperform OpenMP critical sections by 10%. Overall, our study demonstrates that extending OpenMP to include transactions would ease programming effort while allowing improved performance.

show abstract

Section: Introductionmentioning

confidence: 99%

A Case for Including Transactions in OpenMP

Wong

Bihari

Supinski

et al. 2010

Beyond Loop Level Parallelism in OpenMP: Accelerators, Tasking and More

Self Cite

View full text Add to dashboard Cite

show abstract

“…Many optimizations have been proposed for compilers and runtime systems to reduce the overheads of STM read and write operations [Wang et al 2007;Wu et al 2009;Dragojevic et al 2009;Afek et al 2011]. Wang et al [2007] provide compiler optimizations for eliminating unnecessary read/write barriers (read after write barrier, barriers on local variables, etc.)…”

Section: Related Workmentioning

confidence: 99%

“…Until now researchers have been trying to decrease STM overheads by applying various compiler and runtime optimizations on read and write barriers [Wang et al 2007;Wu et al 2009;Dragojevic et al 2009;Afek et al 2011], or by accelerating some STM functionalities in hardware Saha et al 2006;Minh et al 2007;Shriraman et al 2007]. In our work, we follow a different approach and focus on reducing the overheads of starting and committing transactions.…”

Section: Introductionmentioning

confidence: 98%

Profile-guided transaction coalescing—lowering transactional overheads by merging transactions

Stipić

Smiljković

Unsal

et al. 2013

TACO

View full text Add to dashboard Cite

Previous studies in software transactional memory mostly focused on reducing the overhead of transactional read and write operations. In this article, we introduce transaction coalescing, a profile-guided compiler optimization technique that attempts to reduce the overheads of starting and committing a transaction by merging two or more small transactions into one large transaction. We develop a profiling tool and a transaction coalescing heuristic to identify candidate transactions suitable for coalescing. We implement a compiler extension to automatically merge the candidate transactions at the compile time. We evaluate the effectiveness of our technique using the hash table micro-benchmark and the STAMP benchmark suite. Transaction coalescing improves the performance of the hash table significantly and the performance of Vacation and SSCA2 benchmarks by 19.4% and 36.4%, respectively, when running with 12 threads.

show abstract

“…We chose not to apply lock elision to synchronized blocks with writes to local variables that are live at the beginning of the critical section, because otherwise we would need to keep and restore the values that has been kept in such local variables before executing the critical section if the speculative execution of the critical section fails to complete [17]. Although we do not explicitly forbid readonly synchronized blocks from creating new objects by using the new construct, object creation rarely occurs in read-only synchronized blocks because they involve the invocation of constructors where writes to instance variables typically occur.…”

Section: Lock Elision For Read-only Critical Sectionsmentioning

confidence: 99%

Lock elision for read-only critical sections in Java

Nakaike

Michael

2010

Proceedings of the 31st ACM SIGPLAN Conference on Programming Language Design and Implementation

Self Cite

View full text Add to dashboard Cite

It is not uncommon in parallel workloads to encounter shared data structures with read-mostly access patterns, where operations that update data are infrequent and most operations are read-only. Typically, data consistency is guaranteed using mutual exclusion or read-write locks. The cost of atomic update of lock variables result in high overheads and high cache coherence traffic under active sharing, thus slowing down single thread performance and limiting scalability.In this paper, we present SOLERO (Software Optimistic Lock Elision for Read-Only critical sections), a new lock implementation called for optimizing read-only critical sections in Java based on sequential locks. SOLERO is compatible with the conventional lock implementation of Java. However, unlike the conventional implementation, only critical sections that may write data or have side effects need to update lock variables, while read-only critical sections need only read lock variables without writing them. Each writing critical section changes the lock value to a new value. Hence, a read-only critical section is guaranteed to be consistent if the lock is free and its value does not change from the beginning to the end of the read-only critical section.Using Java workloads including SPECjbb2005 and the HashMap and TreeMap Java classes, we evaluate the performance impact of applying SOLERO to read-mostly locks. Our experimental results show performance improvements across the board, often substantial, in both single thread speed and scalability over the conventional lock implementation (mutual exclusion) and read-write locks. SOLERO improves the performance of SPECjbb2005 by 3-5% on single and multiple threads. The results using the HashMap and TreeMap benchmarks show that SOLERO outperforms the conventional lock implementation and read-write locks by substantial multiples on multi-threads.

show abstract

Compiler and runtime techniques for software transactional memory optimization

Cited by 21 publications

References 39 publications

A Case for Including Transactions in OpenMP

A Case for Including Transactions in OpenMP

Profile-guided transaction coalescing—lowering transactional overheads by merging transactions

Lock elision for read-only critical sections in Java

Contact Info

Product

Resources

About