Abstract: A method and apparatus for accelerating a Software Transactional Memory (STM) system is herein described. A data object and metadata for the data object may each be associated with a filter, such as a hardware monitor or ephemerally held filter information. The filter is in a first, default state when no access, such as a read, from the data object has occurred during a pendancy of a transaction. Upon encountering a first access to the metadata, such as a first read, access barrier operations, such as logging of the metadata; setting a read monitor; or updating ephemeral filter information with an ephemeral/buffered store operation, are performed. Upon a subsequent/redundant access to the metadata, such as a second read, access barrier operations are elided to accelerate the subsequent access based on the filter being set to the second state to indicate a previous access occurred.

Abstract: In one embodiment, the present invention includes a method for selecting a first transaction execution mode to begin a first transaction in a unbounded transactional memory (UTM) system having a plurality of transaction execution modes. These transaction execution modes include hardware modes to execute within a cache memory of a processor, a hardware assisted mode to execute using transactional hardware of the processor and a software buffer, and a software transactional memory (STM) mode to execute without the transactional hardware. The first transaction execution mode can be selected to be a highest performant of the hardware modes if no pending transaction is executing in the STM mode, otherwise a lower performant mode can be selected. Other embodiments are described and claimed.

Abstract: A method and apparatus for accelerating transactional execution. Barriers associated with shared memory lines referenced by memory accesses within a transaction are only invoked/executed the first time the shared memory lines are accessed within a transaction. Hardware support, such as a transaction field/transaction bits, are provided to determine if an access is the first access to a shared memory line during a pendancy of a transaction. Additionally, in an aggressive operational mode version numbers representing versions of elements stored in shared memory lines are not stored and validated upon commitment to save on validation costs. Moreover, even in a cautious mode, that stores version numbers to enable validation, validation costs may not be incurred, if eviction of accessed shared memory lines do not occur during execution of the transaction.

Abstract: A method for managing a transaction includes determining that an optimistically immutable field in the transaction is written to. Invaliding a method in response to determining that the method in the transaction reads is the optimistically immutable field. Other embodiments are disclosed and claimed.

Abstract: Methods and systems are provided for managing memory allocations and deallocations while in transactional code, including nested transactional code. The methods and systems manage transactional memory operations by using identifiers, such as sequence numbers, to handle memory management in transactions. The methods and systems also maintain lists of deferred actions to be performed at transaction abort and commit times. A number of memory management routines associated with one or more transactions examine the transaction sequence number of the current transaction, manipulate commit and/or undo logs, and set/use the transaction sequence number of an associated object, but are not so limited. The methods and systems provide for memory allocation and deallocations within transactional code while preserving transactional semantics. Other embodiments are described and claimed.

Abstract: For a variable accessed at least once in a software-based transactional memory system (STM) defined (STM-defined) critical region of a program, modifying an access to the variable that occurs outside any STM-defined critical region system by starting a hardware based transactional memory based transaction, within the hardware based transactional memory based transaction, checking if the variable is currently owned by a STM transaction, checking if the variable is currently owned by a STM transaction; if the variable is not currently owned by a STM transaction, performing the access and then committing the hardware based transactional memory transaction; and if the variable is currently owned by a STM transaction, performing a responsive action.

Abstract: Performing non-transactional escape actions within a hardware based transactional memory system. A method includes at a hardware thread on a processor beginning a hardware based transaction for the thread. Without committing or aborting the transaction, the method further includes suspending the hardware based transaction and performing one or more operations for the thread, non-transactionally and not affected by: transaction monitoring and buffering for the transaction, an abort for the transaction, or a commit for the transaction. After performing one or more operations for the thread, non-transactionally, the method further includes resuming the transaction and performing additional operations transactionally. After performing the additional operations, the method further includes either committing or aborting the transaction.

Abstract: Minimizing code duplication in an unbounded transactional memory system. A computing apparatus including one or more processors in which it is possible to use a set of common mode-agnostic TM barrier sequences that runs on legacy ISA and extended ISA processors, and that employs hardware filter indicators (when available) to filter redundant applications of TM barriers, and that enables a compiled binary representation of the subject code to run correctly in any of the currently implemented set of transactional memory execution modes, including running the code outside of a transaction, and that enables the same compiled binary to continue to work with future TM implementations which may introduce as yet unknown future TM execution modes.

Abstract: Synchronizing threads on loss of memory access monitoring. Using a processor level instruction included as part of an instruction set architecture for a processor, a read, or write monitor to detect writes, or reads or writes respectively from other agents on a first set of one or more memory locations and a read, or write monitor on a second set of one or more different memory locations are set. A processor level instruction is executed, which causes the processor to suspend executing instructions and optionally to enter a low power mode pending loss of a read or write monitor for the first or second set of one or more memory locations. A conflicting access is detected on the first or second set of one or more memory locations or a timeout is detected. As a result, the method includes resuming execution of instructions.

Abstract: Provided is a method, system, and program for coordinating access to memory locations for hardware transactional memory transactions and software transactional memory transactions. A hardware transaction executing in hardware transactional memory initiates a request to access a memory location. A fault is returned to the hardware transaction request in response to an operation by one software transaction executing in a software transactional memory.

Abstract: Object-based conflict detection is described in the context of software transactional memory. In one example, a pointer is received for a block of instructions, the block of instructions having allocated objects. The lower bits of the pointer are masked if the pointer is in a small object space to obtain a block header for the block, and a size of the allocated objects is determined using the block header.

Abstract: A method and apparatus for accelerating transactional execution. Barriers associated with shared memory lines referenced by memory accesses within a transaction are only invoked/executed the first time the shared memory lines are accessed within a transaction. Hardware support, such as a transaction field/transaction bits, are provided to determine if an access is the first access to a shared memory line during a pendancy of a transaction. Additionally, in an aggressive operational mode version numbers representing versions of elements stored in shared memory lines are not stored and validated upon commitment to save on validation costs. Moreover, even in a cautious mode, that stores version numbers to enable validation, validation costs may not be incurred, if eviction of accessed shared memory lines do not occur during execution of the transaction.

Abstract: A method and apparatus for utilizing hardware mechanisms of a transactional memory system is herein described. Various embodiments relate to software-based filtering of operations from read and write barriers and read isolation barriers during transactional execution. Other embodiments relate to software-implemented read barrier processing to accelerate strong atomicity. Other embodiments are also described and claimed.

Abstract: A method and apparatus for unified concurrency control in a Software Transactional Memory (STM) is herein described. A transaction record associated with a memory address referenced by a transactional memory access operation includes optimistic and pessimistic concurrency control fields. Access barriers and other transactional operations/functions are utilized to maintain both fields of the transaction record, appropriately. Consequently, concurrent execution of optimistic and pessimistic transactions is enabled.

Abstract: A method and apparatus for efficiently executing nested transactions is herein described. Hardware support for execution of transactions is provided. Additionally, through the use of logging previous values immediately before a current nested transaction in a local memory and storage of a stack of handlers associated with a hierarchy of transactions, nested transactions are potentially efficiently executed. Upon a failure, abort, or invalidating event/access within a nested transaction, the state of variables or memory locations written to during execution of the nested transaction are rolled-back to immediately before the nested transaction, instead of all the way back to an original state of the variables or memory locations before an enclosing transaction. As a result, nested transactions may be re-executed within enclosing transactions, without flattening the enclosing and nested transactions to re-execute everything.

Abstract: A method and apparatus for accelerating transactional execution. Barriers associated with shared memory lines referenced by memory accesses within a transaction are only invoked/executed the first time the shared memory lines are accessed within a transaction. Hardware support, such as a transaction field/transaction bits, are provided to determine if an access is the first access to a shared memory line during a pendancy of a transaction. Additionally, in an aggressive operational mode version numbers representing versions of elements stored in shared memory lines are not stored and validated upon commitment to save on validation costs. Moreover, even in a cautious mode, that stores version numbers to enable validation, validation costs may not be incurred, if eviction of accessed shared memory lines do not occur during execution of the transaction.

Abstract: A method and apparatus for handling exceptions during execution of a transaction is herein described. A compiler associates a transaction exception handler (TEH) with a transaction in program code, such as through insertion of a call to the TEH. The TEH is also associated with an exception data structure, such as an unwind table, that is utilized during runtime to call an appropriate handler in response to an exception. Additionally, the TEH code is generated by the compiler and inserted into the program code. Upon encountering an exception during execution of the transaction, the TEH is capable of dynamically resizing the transaction to the point of the exception through an attempted commit.

Abstract: Embodiments of the invention provide a programming model for CPU-GPU platforms. In particular, embodiments of the invention provide a uniform programming model for both integrated and discrete devices. The model also works uniformly for multiple GPU cards and hybrid GPU systems (discrete and integrated). This allows software vendors to write a single application stack and target it to all the different platforms. Additionally, embodiments of the invention provide a shared memory model between the CPU and GPU. Instead of sharing the entire virtual address space, only a part of the virtual address space needs to be shared. This allows efficient implementation in both discrete and integrated settings.

Abstract: Methods and systems are provided for managing memory allocations and deallocations while in transactional code, including nested transactional code. The methods and systems manage transactional memory operations by using identifiers, such as sequence numbers, to handle memory management in transactions. The methods and systems also maintain lists of deferred actions to be performed at transaction abort and commit times. A number of memory management routines associated with one or more transactions examine the transaction sequence number of the current transaction, manipulate commit and/or undo logs, and set/use the transaction sequence number of an associated object, but are not so limited. The methods and systems provide for memory allocation and deallocations within transactional code while preserving transactional semantics. Other embodiments are described and claimed.

Abstract: Embodiments of the invention provide language support for CPU-GPU platforms. In one embodiment, code can be flexibly executed on both the CPU and GPU. CPU code can offload a kernel to the GPU. That kernel may in turn call preexisting libraries on the CPU, or make other calls into CPU functions. This allows an application to be built without requiring the entire call chain to be recompiled. Additionally, in one embodiment data may be shared seamlessly between CPU and GPU. This includes sharing objects that may have virtual functions. Embodiments thus ensure the right virtual function gets invoked on the CPU or the GPU if a virtual function is called by either the CPU or GPU.