Version management alternatives for hardware transactional memory

Abstract

Transactional Memory is a promising parallel programming model that addresses the programmability issues of lockbased applications using mechanisms that are transparent to developers. Hardware Transactional Memory (HTM) implements these mechanisms in silicon to obtain better results than fine-grain locking solutions. One of these mechanisms is data version management, that decides how and where the modifications introduced by transactions are stored to guarantee their atomicity and durability.In this paper, we show that aborts are frequent especially for applications with coarse-grain transactions and many threads, and that this severely restricts the scalability of log-based HTMs. To address this issue, we propose the use of a gated store buffer to accelerate eager version management for log-based HTM. Moreover, we propose a novel design, where the store buffer is used to perform lazy version management (similar to Rock [12]) but overflowed transactions execute with a fallback log-based HTM that uses eager version management.Assuming an infinite store buffer, we show that lazy version management is better suited to applications with finegrain transactions while eager version management is better suited to applications with coarse-grain transactions. Limiting the buffer size to 32 entries, we obtain 20.1% average improvement over log-based HTM for applications with fine-grain transactions (using lazy version management) and 54.7% for applications with coarse-grain transactions (using eager version management).Hardware

An integrated pseudo-associativity and relaxed-order approach to hardware transactional memory

“…There is a rich body of research on minimizing these overheads. For example, while TCC, UTM, VTM, LogTM, PTM, XTM, RTM, Scalable-TCC, ObjectTM, FasTM, Reconfigurable-TM, SEL-TM and SUV-TM [Hammond et al 2004]; [Ananian et al 2005]; [Rajwar et al 2005]; [Moore et al 2006]; [Chuang et al 2006]; [Chung et al 2006b]; [Shriraman et al 2007]; [Chafi et al 2007]; [Khan et al 2008]; [Lupon et al 2008] [Lupon et al 2009]; [Armejach et al 2011]; [Zhao et al 2012]; [Yan et al 2012] focus on reducing static overheads on version management, OneTM, DATM, SBCRHTM, ProactiveTM, EasyTM, DynTM, SON-TM, BFGTS-TM, 42:6 Z. Yan et al and ZEBRA [Blundell et al 2007]; [Ramadan et al 2008]; [Titos et al 2009]; [Blake et al 2009]; [Tomic et al 2009]; [Lupon et al 2010]; [Aydonat and Abdelrahman 2010]; [Blake et al 2011]; propose different TM architectures to alleviate the dynamic overheads incurred by transactional conflicts.…”

FASTM: A Log-based Hardware Transactional Memory with Fast Abort Recovery

“…First, this policy minimizes the number of aborts, which become critical in an HTM with software abort recovery (also, by minimizng aborts we are conservative in how much FASTM improves over LogTM-SE). Second, by using the Stall policy for our evaluation it is easier to compare our results with previous LogTM-SE characterizations [12], [14], [17], [18]. In Section IV-E we describe other conflict resolution policies and we discuss about how they behave in LogTM-SE/FASTM.…”

“…Eager log-based systems suffer considerable delays in the execution of conflicting large transactions due to the overheads of abort recovery [17], [18]. Moreover, slow aborts may exacerbate contention, as many conflicts involve transactions in their abort-recovery phase, which in turn provokes more aborts.…”

Hiding rollback latency in log‐based eager hardware transactional memory

“…Such a coupling with underlying architecture can limit its application. Storing the old values in a simple hardware store buffer to speed up the rollback operation was also proposed [4]. Both the approaches always maintain the software log to handle overflows.…”