# Adaptive Versioning in Transactional Memory Systems +
## 2 Related Work
### Persistent TM Systems  
The performance gap of using eager and lazy versioning is relatively well-studied in persistent TM systems. The most closely related work is due to [PERSON] et al. [22], where they empirically evaluated eager and lazy versioning on the open source non-volatile memory library (NVML), PMDK, Ref. [41] for some constrained workloads, and suggested that _\"one versioning method does not fit all workloads\"_. Particularly, they reported that (i) lazy versioning significantly outperforms eager versioning for workloads in which a transaction updates large number of different objects, while it underperforms eager versioning for read-dominated workloads, and (ii) eager versioning is more sensitive to _read-to-write_ ratios whereas lazy versioning is less sensitive to those ratios [22]. The other works mostly proposed methods through either eager or lazy versioning, and there is no work that elaborates the performance gap between eager and lazy versioning. For example, [PERSON] et al. [18] suggested an STM implementation for persistent memory, called NV-Heaps, using eager versioning. [PERSON] et al. [19] suggested a TinySTM [26; 27] variation, called Mnemosynne, for persistent memory using lazy versioning. NV-Heaps[18] and Mnemosynne[19] drew absolutely opposite conclusions on whether eager or lazy versioning is better for persistent memories. The former prefers to use eager versioning, and the latter opts to use lazy \begin{table}
\begin{tabular}{c c c c} \hline \hline  & & **Versioning** & **Eager** \\ \cline{2-4}  & & **Lazy** & **Eager** \\ \hline \multirow{3}{*}{**Conflict**} & **Lazy** & TCC [11], Nonec [15], RSTM [14], SwissTM [16] & None \\ \cline{2-4}  & **Eager** & UTM [10], VTM [13], RSTM [14], SwissTM [16] & UTM [10], LogTM [12], RSTM [14] \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Versioning and conflict detection mechanisms used in some non-persistent TM systems. versioning. Furthermore, many other persistent TM systems such as [20; 42] suggested using eager versioning. [PERSON] et al. [43] studied HTM-based transactions using lazy versioning. DudeTM [21] incorporates lazy versioning in their design where a transaction first runs in volatile memory using any HTM or STM implementation and produces a redo log for that transaction. The redo log is then flushed to persistent memory satisfying atomicity of data and then modify the original data in persistent memory according to the persistent redo log. Notice that this approach is different from ours and needs a shared shadow memory, besides persistent memory where that data is. [PERSON] et al. [44] proposed a low overhead HTM compatible persistent transactional system, called Crafty, using eager versioning. [PERSON] et al. [45] proposed a persistent HTM system providing a hardware support for lazy versioning to reduce the performance overhead compared to software based implementations. Recently, [PERSON] et al. [46] studied the scalability issues with the experimental results on Intel Optane DC [47] persistent memory and proposed scalable persistent hardware transactions (SPHT). [PERSON] et al. [48] have introduced a phase based persistent TM system, NV-PhTM, where the transaction execution mode is switched between two phases, HTM and STM. The best execution mode among the two is selected according to the application's characteristics. This is different than our approach where we switch between the versioning methods within a TM system instead of switching between hardware or software transaction execution mode. The other related works in persistent memory study latency, scalability and ordering constraints problems. [PERSON] et al. [49] proposed a persistent TM system, called TimeStone, that has minimal writes and low memory footprints. [PERSON] et al. [50] presented a read-friendly persistent TM system, called Pisces, that maintains up to two versions of the data using dual-version concurrency control (DVCC) protocol and provides non-blocking reads. [PERSON] et al.