Abstract: Embodiments relate to non-default instruction handling within a transaction. An aspect includes entering a transaction, the transaction comprising a first plurality of instructions and a second plurality of instructions, wherein a default manner of handling of instructions in the transaction is one of atomic and non-atomic. Another aspect includes encountering a non-default specification instruction in the transaction, wherein the non-default specification instruction comprises a single instruction that specifies the second plurality of instructions of the transaction for handling in a non-default manner comprising one of atomic and non-atomic, wherein the non-default manner is different from the default manner. Another aspect includes handling the first plurality of instructions in the default manner. Yet another aspect includes handling the second plurality of instructions in the non-default manner.

Abstract: Embodiments relate to address probing for a transaction. An aspect includes determining, before starting execution of a transaction, a plurality of addresses that will be used by the transaction during execution. Another aspect includes probing each address of the plurality of addresses to determine whether any of the plurality of addresses has an address conflict. Yet another aspect includes, based on determining that none of the plurality of addresses has an address conflict, starting execution of the transaction.

Abstract: Embodiments relate to non-default instruction handling within a transaction. An aspect includes entering a transaction, the transaction comprising a first plurality of instructions and a second plurality of instructions, wherein a default manner of handling of instructions in the transaction is one of atomic and non-atomic. Another aspect includes encountering a non-default specification instruction in the transaction, wherein the non-default specification instruction comprises a single instruction that specifies the second plurality of instructions of the transaction for handling in a non-default manner comprising one of atomic and non-atomic, wherein the non-default manner is different from the default manner. Another aspect includes handling the first plurality of instructions in the default manner. Yet another aspect includes handling the second plurality of instructions in the non-default manner.

Abstract: Avoiding data conflicts includes initiating a transactional lock elision transaction containing a critical section, executing the transactional lock elision transaction including the critical section, and checking a status of a lock prior to a commit point in the transactional lock elision transaction executing, wherein the checking the status occurs after processing the critical section. A determination of whether the status of the lock checked is free is made and responsive to a determination the lock checked is free, a result of the transactional lock elision transaction is committed.

Abstract: A technique for applying hardware transaction memory to an arbitrarily large data structure is disclosed. A data updater traverses the data structure to locate an update point using a lockless synchronization technique that synchronizes the data updater with other updaters that may be concurrently updating the data structure. At the update point, the updater performs an update on the data structure using a hardware transactional memory transaction that operates at the update point.

Abstract: A computer-implemented method includes the following operations. A transactional lock elision transaction including a critical section is executed. The critical section is processed. After the processing of the critical section and prior to a commit point in the transactional lock elision transaction, a status of a lock is checked. Responsive to a determination that a status of the lock is free, a result of the transactional lock elision transaction is committed.

Abstract: In a Hardware Lock Elision (HLE) Environment, predictively determining whether a HLE transaction should actually acquire a lock and execute non-transactionally, is provided. Included is, based on encountering an HLE lock-acquire instruction, determining, based on an HLE predictor, whether to elide the lock and proceed as an HLE transaction or to acquire the lock and proceed as a non-transaction; based on the HLE predictor predicting to elide, setting the address of the lock as a read-set of the transaction, and suppressing any write by the lock-acquire instruction to the lock and proceeding in HLE transactional execution mode until an xrelease instruction is encountered wherein the xrelease instruction releases the lock or the HLE transaction encounters a transactional conflict; and based on the HLE predictor predicting not-to-elide, treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction, and proceeding in non-transactional mode.

Abstract: In a Hardware Lock Elision (HLE) Environment, predictively determining whether a HLE transaction should actually acquire a lock and execute non-transactionally, is provided. Included is, based on encountering an HLE lock-acquire instruction, determining, based on an HLE predictor, whether to elide the lock and proceed as an HLE transaction or to acquire the lock and proceed as a non-transaction; based on the HLE predictor predicting to elide, setting the address of the lock as a read-set of the transaction, and suppressing any write by the lock-acquire instruction to the lock and proceeding in HLE transactional execution mode until an xrelease instruction is encountered wherein the xrelease instruction releases the lock or the HLE transaction encounters a transactional conflict; and based on the HLE predictor predicting not-to-elide, treating the HLE lock-acquire instruction as a non-HLE lock-acquire instruction, and proceeding in non-transactional mode.

Abstract: In a multi-processor transaction execution environment, a transaction executes a hint instruction indicating proximity to completion of the transaction. Pending aborts of the transaction due to memory conflicts are suppressed based on the proximity of the transaction to completion.

Abstract: A transactional memory system determines whether to pass control of a transaction to an about-to-run-out-of-resource handler. A processor of the transactional memory system determines information about an about-to-run-out-of-resource handler for transaction execution of a code region of a hardware transaction. The processor dynamically monitors an amount of available resource for the currently running code region of the hardware transaction. The processor detects that the amount of available resource for transactional execution of the hardware transaction is below a predetermined threshold level. The processor, based on the detecting, saves speculative state information of the hardware transaction, and executes the about-to-run-out-of-resource handler, the about-to-run-out-of-resource handler determining whether the hardware transaction is to be aborted or salvaged.

Abstract: A transactional memory system determines whether to pass control of a transaction to an about-to-run-out-of-resource handler. A processor of the transactional memory system determines information about an about-to-run-out-of-resource handler for transaction execution of a code region of a hardware transaction. The processor dynamically monitors an amount of available resource for the currently running code region of the hardware transaction. The processor detects that the amount of available resource for transactional execution of the hardware transaction is below a predetermined threshold level. The processor, based on the detecting, saves speculative state information of the hardware transaction, and executes the about-to-run-out-of-resource handler, the about-to-run-out-of-resource handler determining whether the hardware transaction is to be aborted or salvaged.

Abstract: A transactional memory system salvages a hardware lock elision (HLE) transaction. A processor of the transactional memory system, based on a detection of a pending point-of-failure in a code region during HLE transactional execution, stops HLE transactional execution prior to the pending point-of-failure in the code region. The processor, based on information about a lock elided, commits a speculative state of the stopped HLE transactional execution that is stored, at least in part, in a gathering store cache. The processor starts non-transactional execution at the point of failure in the code region.

Abstract: A transaction within a computer program or computer application comprises program instructions performing multiple store operations that appear to run and complete as a single, atomic operation. The program instructions forming a current transaction comprise a transaction begin indicator, a plurality of instructions (e.g., store operations), and a transaction end indicator. A near-end of transaction indicator is triggered based on a speculative look ahead operation such that an interfering transaction requiring a halt operation may be delayed to allow the current transaction to end. A halt operation, also referred to as an abort operation, as used herein refers to an operation responsive to a condition where two transactions have been detected to interfere where at least one transaction must be aborted and the state of the processor is reset to the state at the beginning of the aborted transaction by performing a rollback.

Abstract: A transactional memory system dynamically predicts the resource requirements of hardware transactions. A processor of the transactional memory system predicts resource requirements of a first hardware transaction to be executed based on any one of a resource hint and a previous execution of a prior hardware transaction. The processor allocates resources for the first hardware transaction based on the predicted resource requirements. The processor executes the first hardware transaction. The processor saves resource usage information of the first hardware transaction for future prediction.

Abstract: Avoiding data conflicts includes initiating a transactional lock elision transaction containing a critical section, executing the transactional lock elision transaction including the critical section, and checking a status of a lock prior to a commit point in the transactional lock elision transaction executing, wherein the checking the status occurs after processing the critical section. A determination of whether the status of the lock checked is free is made and, responsive to a determination the lock checked is free, a result of the transactional lock elision transaction is committed.

Abstract: A transactional memory system controls the coalescing of outermost memory transactions. The coalescing causing committing of memory store data to memory for a first transaction to be done at transaction execution (TX) end of a second transaction. A processor of the transactional memory system executes a run-time instrumentation program for monitoring and modifying an associated program having a plurality of transactions. Based, at least in part, on an analysis of gathered instrumentation information, the processor dynamically modifies continued execution of the plurality of transactions by adding a coalescing instruction that controls, at least in part, a coalescing of one or more outermost transactions of the plurality of transactions.

Abstract: A transactional memory system salvages a hardware lock elision (HLE) transaction. A processor of the transactional memory system executes a lock-acquire instruction in an HLE environment and records information about a lock elided to begin HLE transactional execution of a code region. The processor detects a pending point of failure in the code region during the HLE transactional execution. The processor stops HLE transactional execution at the point of failure in the code region. The processor acquires the lock using the information, and based on acquiring the lock, commits the speculative state of the stopped HLE transactional execution. The processor starts non-transactional execution at the point of failure in the code region.

Abstract: A transactional memory system determines whether to pass control of a transaction to an about-to-run-out-of-resource handler. A processor of the transactional memory system determines information about an about-to-run-out-of-resource handler for transaction execution of a code region of a hardware transaction. The processor dynamically monitors an amount of available resource for the currently running code region of the hardware transaction. The processor detects that the amount of available resource for transactional execution of the hardware transaction is below a predetermined threshold level. The processor, based on the detecting, saves speculative state information of the hardware transaction, and executes the about-to-run-out-of-resource handler, the about-to-run-out-of-resource handler determining whether the hardware transaction is to be aborted or salvaged.

Abstract: A transactional memory system salvages a hardware transaction. A processor of the transactional memory system records information about an about-to-fail handler for transactional execution of a code region, and records information about a lock elided to begin transactional execution of the code region. The processor detects a pending point of failure in the code region during the transactional execution, and based on the detecting, stops transactional execution at a first instruction in the code region and executes the about-to-fail handler using the information about the about-to-fail handler. The processor, executing the about-to-fail handler, acquires the lock using the information about the lock, commits speculative state of the stopped transactional execution, and starts non-transactional execution at a second instruction following the first instruction in the code region.

Abstract: A transactional memory system salvages a hardware transaction. A processor of the transactional memory system records information about an about-to-fail handler for transactional execution of a code region, and records information about a lock elided to begin transactional execution of the code region. The processor detects a pending point of failure in the code region during the transactional execution, and based on the detecting, stops transactional execution at a first instruction in the code region and executes the about-to-fail handler using the information about the about-to-fail handler. The processor, executing the about-to-fail handler, acquires the lock using the information about the lock, commits speculative state of the stopped transactional execution, and starts non-transactional execution at a second instruction following the first instruction in the code region.