Analysis on semantic transactional memory footprint for hardware transactional memory

Abstract

We analyze various characteristics of semantic transactional memory footprint (STMF) that consists of only the memory accesses the underlying hardware transactional memory (HTM) system has to manage for the correct execution of transactional programs. Our analysis shows that STMF can be significantly smaller than declarative transactional memory footprint (DTMF) that contains all memory accesses within transaction boundaries (i.e., only 8.3% of DTMF in the applications examined). This result encourages processor designers and software toolchain developers to explore new design points for low-cost HTM systems and intelligent software toolchains to find and leverage STMF efficiently. We identify seven code patterns that belong to DTMF, but not to STMF, and show that they take up 91.7% of all memory accesses in transactional boundaries, on average, for the transactional programs examined. A new instruction prefix is proposed to express STMF efficiently, and the existing compiler techniques are examined to check their applicability to deduce STMF from DTMF. Our trace analysis shows that using STMF significantly reduces the ratio of transactions overflowing a 32KB L1 cache, from 12.80% to 2.00%, and substantially lowers the false positive probability of Bloom filters used for transaction signature management, from 23.60% to less than 0.001%. The simulation result shows that the STAMP applications with the STMF expression run 40% faster on average than those with the DTMF expression.

Transactional pre-abort handlers in hardware transactional memory

“…While in the HANDLER state, memory is accessed speculatively or non-speculatively depending on the status of the cache line. Reads or writes to cache lines with the transactional bit set are done speculatively, whereas non-transactional lines and lines not being tracked yet (e.g., cache misses) are done non-speculatively [8,9]. In other words, the transactional bit is left as-is for each access 2 .…”

“…the private L1 cache), and the actual mix of addresses accessed by the transaction, etc. [8,32]. This type of interaction is implementation dependent and hard to predict ahead of time -in many ways this problem is similar to the cache performance analysis problem, which is usually measured at runtime [24] rather than predicted statically.…”

“…Some examples are read-only data or private stack data. Instead of treating all memory operations as speculative, some architectures such as ASF allow the software to selectively choose which operations are speculative, and which are non-speculative [8,9].…”

“…Moreover, abort-mitigating actions like transaction conversion may need to be implemented in a non-speculative manner. Nontransactional operations within a hardware transaction have been explored before, either by using explicitly non-speculative load and store operations [8,9], or via transaction suspend and resume operations [6]. Either way, these require additional hardware specific for this purpose as well.…”