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 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 a hardware transaction can be salvaged. A processor of the transactional memory system begins execution of a transaction in a transactional memory environment. Based on detection that an amount of available resource for transactional execution is below a predetermined threshold level, the processor determines whether the transaction can be salvaged. Based on determining that the transaction can not be salvaged, the processor aborts the transaction. Based on determining the transaction can be salvaged, the processor performs a salvage operation, wherein the salvage operation comprises one or more of: determining that the transaction can be brought to a stable state without exceeding the amount of available resource for transactional execution, and bringing the transaction to a stable state; and determining that a resource can be made available, and making the resource available.

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 predicts the outcome of coalescing 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, the method comprising. A processor of the transactional memory system determines whether a first plurality of outermost transactions from an associated program that were coalesced experienced an abort, the first plurality of outermost transactions including a first instance of a first transaction. The processor updates a history of the associated program to reflect the results of the determination. The processor coalesces a second plurality of outermost transactions from the associated program, based, at least in part, on the updated history.

Abstract: Execution of a transaction may be initiated by a CPU in a transactional execution (TX) environment. A set of TX performance characteristics of the transaction during the transactional execution may be collected and stored in a location specified by an instruction of the transaction when the transactional execution ends or aborts.

Abstract: A computer implemented method and system for evading a floating interruption while a processor is in a transactional-execution (TX) mode. A floating interruption request can be detected, by a floating interrupt control mechanism, for a plurality of processors for execution by any one of the plurality of processors. An evasive action can be initiated for at least one of the plurality of processors in a transactional-execution mode, for evading the floating interruption such that another one of the plurality of processors can execute the floating interruption.

Abstract: Execution of a transaction may be initiated by a CPU in a transactional execution (TX) environment. A set of TX performance characteristics of the transaction during the transactional execution may be collected and stored in a location specified by an instruction of the transaction when the transactional execution ends or aborts.

Abstract: When executed, a transaction-begin instruction specifies an initial value for a transaction-count-to-completion (CTC) value for a transaction. The initial value indicates a predicted duration of the transaction. The CTC value may be a number of instructions to completion or an amount of time to completion. The CTC value is adjusted as the transaction progresses. The adjusted CTC value indicates how far the transaction is from completion. When a disruptive event associated with inducing transactional aborts, such as an interrupt or a conflicting memory access, is identified while processing the transaction, processing of the disruptive event is deferred if the adjusted CTC value satisfies deferral criteria. If the adjusted CTC value does not satisfy deferral criteria, the transaction is aborted and the disruptive event is processed.

Abstract: When executed, a transaction-hint instruction specifies a transaction-count-to-completion (CTC) value for a transaction. The CTC value indicates how far a transaction is from completion. The CTC may be a number of instructions to completion or an amount of time to completion. The CTC value is adjusted as the transaction progresses. When a disruptive event associated with inducing transactional aborts, such as an interrupt or a conflicting memory access, is identified while processing the transaction, processing of the disruptive event is deferred if the adjusted CTC value satisfies deferral criteria. If the adjusted CTC value does not satisfy deferral criteria, the transaction is aborted and the disruptive event is processed.

Abstract: In a multi-processor transaction execution environment a transaction is executed a plurality of times. Based on the executions, a duration is predicted for executing the transaction. Based on the predicted duration, a threshold is determined. Pending aborts of the transaction due to memory conflicts are suppressed based on the transaction exceeding the determined threshold.

Abstract: A transactional memory system salvages a partially executed hardware transaction. A processor of the transactional memory system determines information about an about-to-fail handler for transactional execution of a code region of a hardware transaction. The processor saves state information of the hardware transaction, the state information usable to determine whether the hardware transaction is to be salvaged or to be aborted. The processor detects an about-to-fail condition during the transactional execution of the hardware transaction. The processor, based on the detecting, executes the about-to-fail handler using the information about the about-to-fail handler, the about-to-fail handler determining whether the hardware transaction is to be salvaged or to be aborted.

Abstract: A transactional memory system salvages a partially executed hardware transaction. A processor of the transactional memory system saves state information in a first code region of a first hardware transaction, the state information useable to determine whether the first hardware transaction is to be salvaged or to be aborted. The processor detects an about to fail condition in the first code region of the first hardware transaction. The processor, based on the detecting, executes an about-to-fail handler, the about-to-fail handler using the saved state information to determine whether the first hardware transaction is to be salvaged or to be aborted. The processor executing the about-to-fail handler, based on the transaction being to be salvaged, uses the saved state information to determine what portion of the first hardware transaction to salvage.

Abstract: There is provided an apparatus, a method and computer program product for managing one or more components of an electronic machine. A user connects one or more components to an electronic machine in parallel. The electronic machine determines whether the components are failed. A latch device, attached to each component, automatically locks one or more of the components to the electronic machine if the one or more of the components are not failed. The electromechanical latch automatically releases the one or more of the components from the electronic machine if the one or more of the components are failed.

Abstract: A scheme referred to as a “Region-based cache restoration prefetcher” (RECAP) is employed for cache preloading on a partition or a context switch. The RECAP exploits spatial locality to provide a bandwidth-efficient prefetcher to reduce the “cold” cache effect caused by multiprogrammed virtualization. The RECAP groups cache blocks into coarse-grain regions of memory, and predicts which regions contain useful blocks that should be prefetched the next time the current virtual machine executes. Based on these predictions, and using a simple compression technique that also exploits spatial locality, the RECAP provides a robust prefetcher that improves performance without excessive bandwidth overhead or slowdown.

Abstract: A transactional memory system predicts the outcome of coalescing 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, the method comprising. A processor of the transactional memory system determines whether a first plurality of outermost transactions from an associated program that were coalesced experienced an abort, the first plurality of outermost transactions including a first instance of a first transaction. The processor updates a history of the associated program to reflect the results of the determination. The processor coalesces a second plurality of outermost transactions from the associated program, based, at least in part, on the updated history.

Abstract: Embodiments relate to implementing a coherence protocol. An aspect includes sending a request for data to a remote processor and receiving by a processor a response from the remote processor. The response has a transaction status of a remote transaction on the remote processor. The processor adds the transaction status of the remote transaction on the remote processor in a local transaction interference tracking table.

Abstract: Embodiments relate to implementing a coherence protocol. An aspect includes sending a request for data to a remote processor and receiving by a processor a response from the remote processor. The response has a transaction status of a remote transaction on the remote processor. The processor adds the transaction status of the remote transaction on the remote processor in a local transaction interference tracking table.

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 salvages a partially executed hardware transaction. A processor of the transactional memory system saves state information in a first code region of a first hardware transaction, the state information useable to determine whether the first hardware transaction is to be salvaged or to be aborted. The processor detects an about to fail condition in the first code region of the first hardware transaction. The processor, based on the detecting, executes an about-to-fail handler, the about-to-fail handler using the saved state information to determine whether the first hardware transaction is to be salvaged or to be aborted. The processor executing the about-to-fail handler, based on the transaction being to be salvaged, uses the saved state information to determine what portion of the first hardware transaction to salvage.