Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. Open ended and/or closed ended sequential loops can be transformed to parallel loops. For example, a section of code containing an original sequential loop is analyzed to determine a fixed number of iterations for the original sequential loop. The original sequential loop is transformed into a parallel loop that can generate transactions in an amount up to the fixed number of iterations. As another example, an open ended sequential loop can be transformed into a parallel loop that generates a separate transaction containing a respective work item for each iteration of a speculation pipeline. The parallel loop is then executed using the transactional memory system, with at least some of the separate transactions being executed on different threads.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. Open ended and/or closed ended sequential loops can be transformed to parallel loops. For example, a section of code containing an original sequential loop is analyzed to determine a fixed number of iterations for the original sequential loop. The original sequential loop is transformed into a parallel loop that can generate transactions in an amount up to the fixed number of iterations. As another example, an open ended sequential loop can be transformed into a parallel loop that generates a separate transaction containing a respective work item for each iteration of a speculation pipeline. The parallel loop is then executed using the transactional memory system, with at least some of the separate transactions being executed on different threads.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. A transactional memory system is provided. A first section of code containing an original sequential loop is transformed into a second section of code containing a parallel loop that uses transactions to preserve an original input to output mapping. For example, the original sequential loop can be transformed into a parallel loop by taking each iteration of the original sequential loop and generating a separate transaction that follows a pre-determined commit order process. At least some of the separate transactions are executed in different threads. When an unhandled exception is detected that occurs in a particular transaction while the parallel loop is executing, state modifications made by the particular transaction and predecessor transactions are committed, and state modifications made by successor transactions are discarded.

Abstract: Handling parallelism in transactions. One embodiment includes a method that includes beginning a cache resident transaction. The method further includes encountering a nested structured parallelism construct within the cache resident transaction. A determination is made as to whether the transaction would run faster serially in cache resident mode or faster parallel in software transactional memory mode for the overall transaction. In the software transactional memory mode, cache resident mode is used for one or more hierarchically lower nested transactions. The method further includes continuing the transaction in the mode determined.

Abstract: Handling garbage collection and exceptions in hardware assisted transactions. Embodiments are practiced in a computing environment including a hardware assisted transaction system. Embodiments includes acts for writing to a card table outside of a transaction; handling garbage collection compaction occurring when a hardware transaction is active by using a common global variable and instructing one or more agents to write to the common global variable any time an operation is performed which may change an object's virtual address; acts for managing a thread-local allocation context; acts for handling exceptions while in a hardware assisted transaction.

Abstract: Using cache resident transaction hardware to accelerate a software transactional memory system. The method includes identifying a plurality of atomic operations intended to be performed by a software transactional memory system as transactional operations as part of a software transaction. The method further includes selecting at least a portion of the plurality of atomic operations. The method further includes attempting to perform the portion of the plurality of atomic operations as hardware transactions using cache resident transaction hardware.

Abstract: Hardware assisted transactional memory system with open nested transactions. Some embodiments described herein implement a system whereby hardware acceleration of transactions can be accomplished by implementing open nested transaction in hardware which respect software locks such that a top level transaction can be implemented in software, and thus not be limited by hardware constraints typical when using hardware transactional memory systems.

Abstract: A software transactional memory system is provided with multiple global version counters. The system assigns an affinity to one of the global version counters for each thread that executes transactions. Each thread maintains a local copy of the global version counters for use in validating read accesses of transactions. Each thread uses a corresponding affinitized global version counter to store version numbers of write accesses of executed transactions. The system adaptively changes the affinities of threads when data conflict or global version counter conflict is detected between threads.

Abstract: A software transactional memory system is provided that provides privatization safety. The system identifies situations where the completion of a transaction may be expedited because a privatization artifact will not occur. The system determines whether a privatization artifact may occur using a read and write set intersection test, transactional variables, pessimistic locks, or declared privatizing transactions. If a privatization artifact will not occur for a transaction, then the system may allow the transaction to complete prior to one or more earlier transactions.

Abstract: A software transactional memory system is provided with overflow handling. The system includes a global version counter with an epoch number and a version number. The system accesses the global version counter prior to and subsequent to memory accesses of transactions to validate read accesses of the transaction. The system includes mechanisms to detect global version number overflow and may allow some or all transactions to execute to completion subsequent to the global version number overflowing. The system also provides publication, privatization, and granular safety properties.

Abstract: Transactional memory compatibility type attributes are associated with intermediate language code to specify, for example, that intermediate language code must be run within a transaction, or must not be run within a transaction, or may be run within a transaction. Attributes are automatically produced while generating intermediate language code from annotated source code. Default rules also generate attributes. Tools use attributes to statically or dynamically check for incompatibility between intermediate language code and a transactional memory implementation.

Abstract: A transactional memory processing system provides for the integration of transactional memory concepts at the compiler-level into a higher-level traditional transaction processing system. Atomic blocks at the compiler-level can be specified as atomic block transactions and include the features of atomicity and isolation. Actions within this atomic block transaction include the enlistment of resource managers from a repository. The repository can now include a pre-programmed memory resource manager to manage the transactional memory. As in traditional transactions, a commit protocol can be used to determine if the actions are valid and can be exposed outside of the transaction. Unlike traditional transactions, however, the transaction is not necessarily doomed if all of the actions are not validated. Rather, memory conflicts can cause a rollback and re-execution of the atomic block transaction, which can be repeated as long as necessary, until the memory resource manger votes to commit.

Abstract: A software transactional memory system is provided that creates an array of transactional locks for each array object that is accessed by transactions. The system divides the array object into non-overlapping portions and associates each portion with a different transactional lock. The system acquires transactional locks for transactions that access corresponding portions of the array object. By doing so, different portions of the array object can be accessed by different transactions concurrently. The system may use a shared shadow or undo copy for accesses to the array object.

Abstract: A dynamic race detection system is provided that detects race conditions in code that executes concurrently in a computer system. The dynamic race detection system uses a modified software transactional memory (STM) system to detect race conditions. A compiler converts portions of the code that are not configured to operate with the STM system into pseudo STM code that operates with the STM system. The dynamic race detection system detects race conditions in response to either a pseudo STM transaction in the pseudo STM code failing to validate when executed or an actual STM transaction failing to validate when executed because of conflict with a concurrent pseudo STM transaction.

Abstract: A compiler is provided that determines when the use of software transactional memory (STM) primitives may be optimized with respect to a set of collectively dominating STM primitives. The compiler analysis coordinates the use of variables containing possible shadow copy pointers to allow the analysis to be performed for both direct write and buffered write STM systems. The coordination of the variables containing the possible shadow copy pointers ensures that the results of STM primitives are properly reused. The compiler analysis identifies memory accesses where STM primitives may be eliminated, combined, or substituted for lower overhead STM primitives.

Abstract: A software transactional memory system is provided that generates and stores compressed transactional locks in a portion of object headers. The software transactional memory system allocates preferred write log memory with a predefined size of memory that corresponds to a number of bits in the compressed transactional locks. The compressed transactional locks identify write log entries in corresponding write logs in the preferred write log memory. If the preferred write log memory becomes full, additional write log memory is allocated for write log entries and subsequent transactional locks are stored uncompressed in an auxiliary memory. A pointer that may be used to locate the uncompressed transactional lock is stored in the header. If an object header with a compressed transactional lock is needed for another use, the compressed transactional lock is uncompressed and stored in the auxiliary memory. A pointer that may be used to locate the uncompressed transactional lock is stored in the header.

Abstract: Software transactional memory (STM) primitives are provided that allow the results of prior open calls to be used by subsequent open calls either as-is or through another STM primitive that consumes the results of the previous invocation. The STM primitives are configured to ensure that the address of a shadow copy representing a memory location will not changed across a wide range of operations and thereby enable re-use of the shadow copy.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. Open ended and/or closed ended sequential loops can be transformed to parallel loops. For example, a section of code containing an original sequential loop is analyzed to determine a fixed number of iterations for the original sequential loop. The original sequential loop is transformed into a parallel loop that can generate transactions in an amount up to the fixed number of iterations. As another example, an open ended sequential loop can be transformed into a parallel loop that generates a separate transaction containing a respective work item for each iteration of a speculation pipeline. The parallel loop is then executed using the transactional memory system, with at least some of the separate transactions being executed on different threads.

Abstract: Various technologies and techniques are disclosed for transforming a sequential loop into a parallel loop for use with a transactional memory system. A transactional memory system is provided. A first section of code containing an original sequential loop is transformed into a second section of code containing a parallel loop that uses transactions to preserve an original input to output mapping. For example, the original sequential loop can be transformed into a parallel loop by taking each iteration of the original sequential loop and generating a separate transaction that follows a pre-determined commit order process. At least some of the separate transactions are executed in different threads. When an unhandled exception is detected that occurs in a particular transaction while the parallel loop is executing, state modifications made by the particular transaction and predecessor transactions are committed, and state modifications made by successor transactions are discarded.

Abstract: A method and apparatus for transforming large messages using a scalable process. This scalable process decomposes the message into nodes and node values. Navigation between related tree node tree is carried out based upon the decomposed message. Following decomposition a first node to be transformed is retrieved. Following retrieval of the first node a second node to be transformed is requested. The process obtains the node from the node files. This process repeats until the message is transformed.