Sandboxing transactional memory

Abstract

Correct transactional memory systems (TMs) must address the possibility that a speculative transaction may read mutually inconsistent values from memory and then perform an operation that violates the underlying language semantics. TMs for managed languages can leverage type safety, just-intime compilation, and fully monitored exceptions to sandbox transactions, isolating the rest of the system from damaging effects of inconsistent speculation. In contrast, TMs for unmanaged languages that lack these properties typically avoid erroneous behavior by validating a transaction's view of memory incrementally after each read operation.Recent results suggest that performing validation out-ofband can increase performance by factors of 1.7× to 5.2× over incremental validation, but allowing a transaction's main computation to progress in parallel with validation introduces periods in which inconsistent speculative execution may violate language semantics. Without sandboxing-which some authors have suggested is not possible in unmanaged languages-programmers must manually annotate transactions with validation barriers whenever inconsistency might lead to semantic violations, an untenable task.In this work we demonstrate that sandboxing for out-ofband validation is, in fact, possible in unmanaged languages. Our implementation integrates signal interposition, periodic validation, and a mix of static and dynamic instrumentation into a system comprising the LLVM-based Dresden TM compiler and the RSTM runtime. We show that these mechanisms introduce negligible overhead, thus extending the results of out-of-band validation to POSIX programs without requiring manual annotation. Furthermore, we establish sandboxing as a technique that can complement, or replace, incremental validation in any TM that keep speculatively written values in a private buffer.

Low-overhead software transactional memory with progress guarantees and strong semantics

“…(Lazy mechanisms provide two additional benefits in prior work. First, they help to provide sandboxing guarantees for unsafe languages such as C and C++ [13]. In contrast, our design targets safe languages and does not require sandboxing; Section 3.6.…”

“…Since our design targets managed languages that provide memory and type safety, zombie transactions cannot cause memory corruption or other arbitrary behaviors [13,18,36]. A design for unmanaged languages (e.g., C/C++) would need to check for unserializable behavior more aggressively [13].…”

“…A design for unmanaged languages (e.g., C/C++) would need to check for unserializable behavior more aggressively [13].…”

Remote Invalidation: Optimizing the Critical Path of Memory Transactions

“…However, it does not decrease the time complexity of incremental validation (like InvalSTM). Moreover, it does not guarantee opacity and needs a sand-boxing mechanism to be consistent [20]. III.…”

Processing transactions in a predefined order

“…An example of such a system is Lerna [35]. In those systems, a sandboxing [7] mechanism prevents computation exceptions to be propagated outside the concurrency control engine.…”