# Adaptive Versioning in Transactional Memory Systems +
## 1 Introduction
### Contributions  
In this article, we demonstrate that we can obtain the best of both worlds without any a priori knowledge on the workload and contention scenario. Particularly, we present an _adaptive_ versioning for TM systems, which we call Adaptive, that dynamically switches the execution using either lazy or eager versioning at runtime, always achieving performance on any workload and contention scenario better than that is obtained using either lazy or eager versioning individually. We provide two different models of Adaptive, one for persistent TM systems and another for non-persistent TM systems. We reported a preliminary version of Adaptive for persistent TM systems in [24]. We reported a preliminary version of Adaptive for non-persistent TM systems in [25]. This article combines and extends those preliminary versions with a full set of experimental results. For the experimental evaluation in both the systems, we incorporated Adaptive in the latest TinySTM implementation [26; 27] and ran experiments against a diverse set of TM benchmarks [26; 27; 28]. Specifically, we used 5 micro-benchmarks (bank, red black tree, hash set, linked list, and skip list) and 8 complex benchmarks (yada, vacation, ssca2, labyrinth, kmeans, intruder, genome, and bayes) from STAMP and STAMPEDE benchmarks [23; 29]). We measured the performance of Adaptive w.r.t. four crucial performance metrics. * **execution time:** the total time to complete executing a set of transactions. This is the time interval from the beginning of the first transaction executed until the last transaction finishes and commits. In a dynamic setting, the execution time translates to _throughput_, the number of committed transactions per time step. * **number of aborts:** the total number of transaction aborts until the current time. If compared with the total number of transaction commits until the current time, it provides _abort-to-commit ratio_ (ACR), a useful metric. The number of aborts directly affect execution time since it is likely that the execution time increases with the increasing number of aborts requiring more number of transaction restarts. * **total number of data movements (for persistent TM systems only):** the total number of movements of data to and from the original memory addresses. The execution time of transactions in persistent memory is directly affected by the number of reads and writes to the PM. The total number of reads and writes to the persistent memory addresses can also be defined as the total number of movements of data to and from the memory addresses. Thus, minimizing the total number of data movements decreases the total execution time of the transactions in PM. * **total number of stores to persistent memory (for persistent TM systems only):** the total number of writes to the persistent memory addresses. The motivation behind this performance metric is as follows. It has been heavily advocated that persistent memories significantly outperform traditional dynamic random access memories (DRAMs) due to low standby power, higher memory density, and much lower cost/bit [30; 31]. However, persistent memories suffer from the _write endurance_ problem, i.e., every persistent memory (PM) unit can sustain a very limited number of writes (i.e., stores) before it wears-out. Minimizing the total number of stores to the PM helps in mitigating the write-endurance problem in PM. In persistent TM systems, the results suggest that, when using _lazy_ versioning with encounter time locking (the two variants _encounter-time-locking_ and _commit-time-locking_ of the lazy versioning are described in Section 6.1), Adaptive achieves up to 1.21\(\times\) better performance (i.e., 17% less execution time) than eager versioning and up to 1.27\(\times\) better performance (i.e., 21% less execution time) than lazy versioning.