# Adaptive Versioning in Transactional Memory Systems +
## 1 Introduction
If \(T_{x}\) commits, the data in the log area is simply discarded. Figure (**b**) depicts three kinds of operations in lazy versioning. The first operation is to copy the data from original memory locations to a log area (called _redo_ log). Transaction \(T_{x}\) updates on this redo log. The second operation is to persist the redo log in persistent memory and the third operation is to copy the updated data back from redo log to the original memory locations. The second and third operations are required only in case \(T_{x}\) commits. If \(T_{x}\) aborts, the data in the redo log area in cache is simply discarded. We conducted a study to validate whether the conclusion from [22] also applies to non-persistent TM systems. Particularly, we executed _genome_ and _kmeans_ benchmarks from STAMP benchmark suite [23] using lazy and eager versioning and measured performance through execution time and number of aborts under varying number of threads (Refer to Section 6 for details on the experimental setup and implementation). The results obtained are shown in Figure 3.  
The results show that lazy versioning performs well for _genome_ whereas the opposite is true for _kmeans_, which is in line of the conclusion drawn in [22]. Again, this discrepancy in performance is mainly because of the fact that the versioning used is not appropriate for the workload and caused more number of aborts, subsequently increasing the execution time. This raises the question of how to choose the versioning method that is appropriate for an application, without a priori knowledge on the workload and contention scenario. However, this is a challenging issue, particularly due to the fact that (i) to select an appropriate versioning, a priori knowledge on the workload (write-dominated or read-dominated) and contention scenario (low or high) is needed, and (ii) such knowledge is difficult to obtain prior to runtime. Figure 3: An illustration of performance discrepancies in execution time (**left**) and number of aborts (**right**) in _genome_ and _kmeans_ benchmarks using eager and lazy versioning in non-persistent TM systems. Figure 2: An illustration of how a transaction \(T_{x}\) is executed in non-persistent memory using (**a**) eager versioning and (**b**) lazy versioning. Figure (**a**) depicts two kinds of operations in eager versioning. The first operation is to copy the data from original memory locations to a log area (called _undo_ log) in cache. Transaction \(T_{x}\) then performs in-place updates to the original memory locations. Now, the second operation is to copy the data back from the log area to the original memory locations, in case \(T_{x}\) aborts. If \(T_{x}\) commits, the data in the log area is simply discarded. Figure (**b**) depicts two kinds of operations in lazy versioning. The first operation is to copy the data from original memory locations to a log area (called _redo_ log) in cache. Transaction \(T_{x}\) updates on this redo log. Then, the second operation is to copy updated data from the log area to the original memory locations, in case \(T_{x}\) commits. If \(T_{x}\) aborts, the data in the log area is simply discarded.