Lock elision for read-only critical sections in Java

Abstract

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.

Instrumentation bias for dynamic data race detection

“…FIB provides analysis atomicity for no added cost on common-case threadlocal and read-shared accesses by introducing safe synchronous coordination between threads in uncommon cases. Shifting blanket pessimistic synchronization overhead to rare cooperative events can reduce overall cost, an insight whose foundations are exploited in diverse ways by cooperative systems such as cache coherence [Papamarcos and Patel 1984], biased locking [Bacon et al 1998;Kawachiya et al 2002;Nakaike and Michael 2010;Pizlo et al 2011;Rajwar and Goodman 2001;Rogers and Iyengar 2011;Russell and Detlefs 2006;Vasudevan et al 2010], the Octet dependence tracker [Bond et al 2013] and other cooperative techniques for object-granularity race detection [von Praun and Gross 2001], and the RADISH hardware-supported data race detector [Devietti et al 2012]. Unlike these systems, most status information and checks used by the FIB cooperative protocol incur no extra cost, since they are derived from existing data race detection metadata and logic.…”

Towards Automatic Lock Removal for Scalable Synchronization

“…Lock Elision Our transformation is inspired by the idea of sequential locks [37] and the approach presented in [39], which replace locks with optimistic concurrency control in read-only transactions. But in contrast to these works, we handle read-only prefixes of transactions (operations) that do update the shared memory.…”

Data-race exceptions have benefits beyond the memory model

“…Though the cost of memory ordering via CAS and fences was substantial, lock elision achieved performance gains of up to 5% [22]. In comparison, DRE-based optimistic synchronization is safe for a larger class of critical sections and memory ordering costs may be absorbed by data-race detection cost.…”

“…Our transformation is similar to eagerupdate/eager-conflict-detection TM [16]; we avoid problems of escaping and rollback by restricting the transformation to limited critical sections. DRE-based optimistic synchronization makes a compromise, supporting more (but not all) critical sections than software lock elision [22], with no specialized support beyond DREs.…”