Begin and Commit

Starting a transaction in ASF-TM requires more care than in an STM and has several implications for the implementation of other TM functions. Therefore, I will discuss this in more detail. The ABI requires the TM to provide a single function to start a transaction (ITM beginTransaction), which will return more than once when transactions are restarted. The SPECULATE instruction of ASF provides similar functionality but we cannot rely on the compiler to insert aSPECULATEinstruction into the application code because this is not possible with the current ABI. Furthermore, the TM needs to execute additional code (e. g., synchronization code related to serial–irrevocable mode) before starting a transaction. This code might not be able to run in a speculative region, so it needs to be executed before the speculative region is started withSPECULATE. Also, keeping as much code as possible out of the speculative region eases the implementation because code executed from within a speculative region needs to be robust to asynchronous aborts (see Section 7.2.4).

Figure 7.5 shows the implementation of ITM beginTransaction in ASF-TM. Its first part up to line 5 issetjmp-like functionality and saves callee-saved regis-

ters on the stack. This is necessary because ASF only restores the stack pointer when restarting a speculative region.

Next, we call ASFTMBegin on line 8, supplying as arguments (1) the first argument of ITM beginTransactionand (2) the address of the the saved registers on the stack.6 This function then has to (1) copy the registers on the stack to a per-transaction buffer so that they can later be restored when restarting the transaction, (2) decide between executing as a hardware or as a software transaction or in serial–irrevocable mode, and (3) start a software transaction or preprare for the execution of a hardware transaction, respectively.

ASF only supports flat nesting (i. e., transactions are always completely rolled back and the outermost transaction is restarted). Therefore,ASFTMBegin basically has to just increment a nesting counter in the case of nested transac- tions. In case of outermost transactions, ASFTMBeginwill be executed before we start a speculative region, so it does not have to deal with asynchronous aborts.

ASFTMBegin must return the value that would otherwise be returned from ITM beginTransaction. Unless the former decided to run uninstrumented code or software-only code paths (line 11), we start the speculative region by execut- ing the SPECULATE instruction (line 14) and then run TM code that has to be executed from within the speculative region (ASFTMPostSpeculate, see Sec- tion 7.3.2 for examples). Finally, we return to the transaction (line 19), which will execute the proper code path.

If the speculative region aborts, ASF will roll back all speculatively modified cache lines and resume execution at line 15. However, the TM still has to run the software-only implementation parts of the transaction abort, so we detect this and branch to the restart handling starting at line 22. We callASFTMRestart, which finishes the software-side abort of the current transaction (e. g., rolls back memory allocations) and callsASFTMBeginto start a new transaction. Because of flat nesting, it is not executed inside a speculative region and thus does not need to be robust to asynchronous aborts. Next, unless we have to restart as a software transaction (line 11), we execute a second SPECULATEinstruc- tion. Finally, because this is a restarted transaction, we jump to a function (line 30) that will (1) call ASFTMPostSpeculate if in a hardware transaction and (2) use the saved registers to return directly from the application’s call to

ITM beginTransaction, similar to whatlongjmpdoes.7

ASF-TM uses a simple policy to decide whether to execute hardware or software transactions. Each invoked transaction is first executed as a hardware transaction. On hardware-transaction aborts due to far calls, disallowed oper- ations, exceeded ASF capacity8_{, or serial–irrevocable mode requests, ASF-TM}

will restart the transaction as a software transaction. When software transac- tions abort, they will never be switched to hardware transactions. On aborts caused by contention between speculative regions and other accesses, ASF-TM uses a simple back-off strategy and only switches to a software transaction if the transaction encountered a large number9 of aborts caused by contention. 6 _{ITM beginTransactionis declared to take a variable number of arguments, but ASF-}

TM currently considers only the first argument.

7_{To work correctly, ITM beginTransactionmust not be inlined into the calling function.} 8_{If only serial–irrevocable mode is available as software fallback, only the second capacity-}

related abort will cause a switch to a software transaction

1 Load64: // arguments: address in %rsi

2 lock mov (%rsi), %rax

3 retq

4

5 Store64: // arguments: address in %rsi, value in %rdx

6 lock mov %rdx, (%rsi)

7 retq

Figure 7.6: 64-bit load and store functions in an ASF-based HTM.

1 lock mov (%r15),%r15 // load address of first node from list head

2 loop:

3 mov %r15,%rax

4 lock mov 0x8(%rax),%r15 // load address of next node 5 lock mov (%r15),%rcx // load node value

6 cmp %r14,%rcx

7 jl loop

Figure 7.7: A transactional traversal of a linked list using an ASF-based HTM and link-time optimization.

This policy guides the execution of a single transaction including all its restarts, but does not try to take the results of the execution of other transactions into account. A proper tuning of this policy at runtime could increase performance. Commiting a hardware transaction is straight-forward becauseCOMMITcan be called anywhere in the call stack. ACOMMITthat causes the transaction to abort is not different to an asynchronous abort, which can also happen anytime (see Section 7.2.4 for further discussion of asynchronous aborts).