Abstract: A software transactional memory system implements a lightweight key-based action framework. The framework includes a set of unified application programming interfaces (APIs) exposed by an STM library that allow clients to implement actions that can be registered, queried, and updated using specific keys by transactions or transaction nests in STM code. Each action includes a key, state information, and a set of one or more callbacks that can be hooked to the validation, commit, abort, and/or re-execution phases of transaction execution. The actions extend the built-in concurrency controls of the STM system with customized control logics, support transaction nesting semantics, and enable integration with garbage collection systems.

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 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 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: 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: 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: Embodiments are directed to implementing a generic SIMD data type in software code. In an embodiment, a computer system accesses a portion of software code that includes an algorithm with a generic SIMD data type that includes a variable number of elements. The algorithm with the generic SIMD data type is to be processed by a specific processor that includes various specific hardware features. The computer system determines at runtime a portion of customized processor-specific code that is to be used with the specified processor based on the generic SIMD data type, wherein the runtime determination resolves the number of elements that are to be used with the specified processor. The computer system also processes the software code including the algorithm with the generic SIMD data type using the determined, customized processor-specific code.

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 hosted pre-compilation system is described herein that provides a way to enable ahead-of-time compilation for managed code running inside a host. The host triggers ahead-of-time compilation at application runtime, after any configuration settings are available. The host can choose which modules to compile, when to compile them, and where to persist the generated images. Upon detecting a module load, the host can trigger pre-compilation, provide the loader an existing pre-compiled image of the module, or do nothing. The runtime/platform validates the integrity of any host-supplied pre-compiled image and provides application programming interfaces (APIs) to inform the host when an image becomes invalid and fails to load. The platform also provides APIs to let the host trigger compilation of binaries at any time relevant to the host, and to generate the images either synchronously or in a background process.

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 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 software transactional memory (STM) system allows the composition of traditional lock based synchronization with transactions in STM code. The STM system acquires each traditional lock the first time that a corresponding traditional lock acquire is encountered inside a transaction and defers all traditional lock releases until a top level transaction in a transaction nest commits or aborts. The STM system maintains state information associated with traditional lock operations in transactions and uses the state information to eliminate deferred traditional lock operations that are redundant. The STM system integrates with systems that implement garbage collection.

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: Handling parallelism in transactions. A method 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: 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: Embodiments are directed to implementing a generic SIMD data type in software code. In an embodiment, a computer system accesses a portion of software code that includes an algorithm with a generic SIMD data type that includes a variable number of elements. The algorithm with the generic SIMD data type is to be processed by a specific processor that includes various specific hardware features. The computer system determines at runtime a portion of customized processor-specific code that is to be used with the specified processor based on the generic SIMD data type, wherein the runtime determination resolves the number of elements that are to be used with the specified processor. The computer system also processes the software code including the algorithm with the generic SIMD data type using the determined, customized processor-specific code.

Abstract: A scalable locking system is described herein that allows processors to access shared data with reduced cache contention to increase parallelism and scalability. The system provides a reader/writer lock implementation that uses randomization and spends extra space to spread possible contention over multiple cache lines. The system avoids updates to a single shared location in acquiring/releasing a read lock by spreading the lock count over multiple sub-counts in multiple cache lines, and hashing thread identifiers to those cache lines. Carefully crafted invariants allow the use of partially lock-free code in the common path of acquisition and release of a read lock. A careful protocol allows the system to reuse space allocated for a read lock for subsequent locking to avoid frequent reallocating of read lock data structures. The system also provides fairness for write-locking threads and uses object pooling techniques to make reduce costs associated with the lock data structures.

Abstract: A software transactional memory system implements a lightweight key-based action framework. The framework includes a set of unified application programming interfaces (APIs) exposed by an STM library that allow clients to implement actions that can be registered, queried, and updated using specific keys by transactions or transaction nests in STM code. Each action includes a key, state information, and a set of one or more callbacks that can be hooked to the validation, commit, abort, and/or re-execution phases of transaction execution. The actions extend the built-in concurrency controls of the STM system with customized control logics, support transaction nesting semantics, and enable integration with garbage collection systems.

Abstract: A software transactional memory (STM) system allows the composition of traditional lock based synchronization with transactions in STM code. The STM system acquires each traditional lock the first time that a corresponding traditional lock acquire is encountered inside a transaction and defers all traditional lock releases until a top level transaction in a transaction nest commits or aborts. The STM system maintains state information associated with traditional lock operations in transactions and uses the state information to eliminate deferred traditional lock operations that are redundant. The STM system integrates with systems that implement garbage collection.

Abstract: A hosted pre-compilation system is described herein that provides a way to enable ahead-of-time compilation for managed code running inside a host. The host triggers ahead-of-time compilation at application runtime, after any configuration settings are available. The host can choose which modules to compile, when to compile them, and where to persist the generated images. Upon detecting a module load, the host can trigger pre-compilation, provide the loader an existing pre-compiled image of the module, or do nothing. The runtime/platform validates the integrity of any host-supplied pre-compiled image and provides application programming interfaces (APIs) to inform the host when an image becomes invalid and fails to load. The platform also provides APIs to let the host trigger compilation of binaries at any time relevant to the host, and to generate the images either synchronously or in a background process.