# Adaptive Versioning in Transactional Memory Systems +
## 2 Related Work
### Non-Persistent (Volatile) TM Systems  
There are several previous studies in non-persistent TM systems, e.g., [10; 11; 12; 14; 15; 16]. Table 2 shows the versioning mechanisms used in some widely-popular non-persistent TM systems. The previous studies used either eager or lazy versioning individually. There is no work that elaborates on the impact of using eager and lazy versioning on  
\begin{table}
\begin{tabular}{c c c} \hline
**Constraint** & **Eager Versioning** & **Lazy Versioning** \\ \hline _Memory Update_ & performs in-place memory update & updates are written to memory at the commit time \\ \hline _Reading Overhead_ & allows to read most recent data & reads are intercepted and redirected to the redo log area to read recent uncommitted data \\ \hline _Persist Ordering_ & **requires to ensure persist ordering for** & **requires only one persist ordering** \\ **(only for persistent TMs)** & **each memory write in a transaction [19]** & **for each transaction [19; 21]** \\ \hline \multirow{3}{*}{_Data Movement_} & transaction aborts are costly as the memory updates need to be rolled back to consistent state using undo log & transaction commits are costly as the updates need to be written back to original memory using redo log \\ \cline{1-1} \cline{2-3}  & & \\ \cline{1-1} \cline{2-3}  & & \\ \cline{1-1} \cline{2-3}  & & \\ \end{tabular}
\end{table}
Table 1: A comparison of _eager_ and _lazy_ versioning in persistent and non-persistent TM systems (_the row in bold text is only for persistent TM systems_).  
the performance of non-persistent TM systems. In fact, the majority of well-known non-persistent TM systems make contradictory conclusions on whether to use eager versioning or lazy versioning. For example, consider two widely popular HTM implementations LoGTM [12] and UTM [10]. They advocate that TM should ideally use eager versioning and eager conflict detection (discussed in Section 3.5) since in eager versioning transaction commits are faster than transaction aborts. Moreover, commits are much more common than aborts in practical applications. In addition, eager conflict detection finds conflicts early and reduces the wasted work by conflicting transactions. On the other hand, consider another widely popular HTM implementation TCC [11]. They use lazy versioning and lazy conflict detection. Other HTMs such as VTM [13] and LTM [10] advocate lazy versioning with eager conflict detection. This is also the case in STMs as some use eager, some use lazy, and some use the combination of eager and lazy approaches of versioning and conflict detection methods, e.g., [14; 15; 16].  
The other line of work is Hybrid TM systems (HyTMs) [32; 33; 34; 35; 36; 37] where transactions are dynamically executed either in HTM or STM implementation. However, it is challenging and complicated to manage the concurrent execution of both hardware and software transactions in HyTM [33]. Therefore, to address this, in 2007, [PERSON] et al. [38] proposed Phased Transactional Memory (PhTM) system to allow the execution of transactions in phases such that each phase is run in the same mode (HTM or STM) and the switching between them is supported seamlessly. PhTM benefits as it does not require coordination between transactions running in different modes. Recently, [PERSON] et al. presented an improved version (PhTM*) [39] and its effectiveness in [40] by avoiding unnecessary switches to software mode. Both approaches, HyTM and PhTM, focus on getting better performance by dynamically switching between the HTM and STM implementations. This is different from the approach we present in this article since we deal with dynamically switching between eager and lazy versioning method at runtime to improve performance of a TM implementation, whereas the HyTM and PhTM approaches deal with switching between HTM and STM implementations.