@proceedings {wtm:2012:dias,
	title = {In-Place Metainfo Support in DeuceSTM},
	journal = {Talk presented at the 2nd Euro-TM Workshop on Transactional Memory},
	year = {2012},
	note = {<p>Workshop talk</p>
},
	address = {Bern, Switzerland},
	abstract = {<p>Several Software Transactional Memory (STM) algorithms have been developed in the last few years. These algorithms differ in many different properties, such as progress and safety guarantees, contention management, etc. Some STM frameworks (DSTM2, DeuceSTM) were developed to allow the implementation and comparison of many different algorithms using the same transactional interface. The information required by an STM algorithm is either associated with the execution of a transaction (frequently referred as transaction descriptor), or associated with each memory location (or object reference) accessed within the transaction. The transaction descriptor is typically stored in a thread-local memory space and maintains the information necessary to validate and commit a memory transaction. The information associated with each memory location depends on the nature of the STM algorithm, which we will henceforth refer to as metadata, and may be composed by e.g. locks, timestamps or version lists. Since metadata is associated with each memory location, there are two main strategies regarding the location for storing such metadata: The metadata is stored either near each memory location (in-place strategy); or in a mapping table that associates the metadata with the corresponding memory location (out- place strategy). DeuceSTM is one of the most efficient STM frameworks available for the Java programming language and provides a well defined interface that allows to implement several STM algorithms using an out-place strategy. This work describes the adaptation and extension of DeuceSTM to support the in-place metadata strategy. Our approach complies to the following properties: Efficiency {\textendash}- The STM implementation does not rely on an auxiliary mapping table, thus providing faster direct access to the transactional metadata; Non-transactional code is oblivious to the presence of metadata in objects, hence there is no performance overhead whatsoever for non-transactional code; Transactional code avoids the extra memory dereference imposed by the decorator pattern; Primitive types are fully supported, even in transactional code; And we provide a solution for fully supporting transactional N-dimensional arrays, which again impose no overhead on non-transactional code. Transparency {\textendash}- The STM implementation automatically identifies, creates and initializes the necessary additional metadata fields in the objects; Non-transactional code is oblivious to the presence of metadata in objects, hence no code changes are required; The new transactional array types (supporting metadata for individual cells) are compatible with the standard arrays, hence not requiring any pre-/post- processing of the arrays when invoking standard or third-party non-transactional libraries. Performance benchmarking has confirmed that our approach for supporting in-place metadata in DeuceSTM, alongside with the existing out-place strategy, is a valid functional complement, widening the range of algorithms that can be efficiently implemented in DeuceSTM, enabling their fair comparison in a common infrastructure.</p>
},
	attachments = {https://sites.fct.unl.pt/sites/default/files/synergy-vm/files/wtm12-presentation.pptx_.pdf},
	author = {Ricardo J. Dias and Vale, Tiago M. and Jo{\~a}o M. Louren{\c c}o}
}
