Abstract: Object relocation often involves a multi-word copy of the object from a source address to a destination address, followed by updating the references (e.g., pointers) to the object. However, during the relocation, other threads may write to portions of the object that have already been relocated, and the updates may be lost when the references are updated to point to the destination address. A non-blocking relocation technique may be implemented to permit threads to write to the object during the relocation, wherein the memory accesses are monitored for a write to the object. If a write is detected during the relocation, the relocation fails and the memory at the destination address is deallocated; but if no write is detected, the relocation succeeds and the references are updated to point to the destination address. Refinements of this technique may be implemented to reduce other synchronization issues.

Abstract: Concurrent, incremental, and lock-free stack scanning for garbage collectors is disclosed. This method uses a summary table and return barriers to allow high responsiveness. The method also supports programs that employ fine-synchronization to avoid locks, imposes negligible overhead on program execution, can be used with existing concurrent collectors, and supports the special in-stack references existing in languages such as C#.

Abstract: Mechanism that employs code cloning and specialized code execution for barriers to minimize runtime overhead. This is facilitated by duplicating code and inserting specializations of the barriers in the code copies. The mechanism is effective for garbage collection when the garbage collection executes through different phases, and the barrier behavior and overheads depend on these phases. The duplicated and specialized code enables the program to run efficiently by reducing the dynamic count of a phase check when the phase is well-known and phase checks can be avoided.

Abstract: Object relocation often involves a multi-word copy of the object from a source memory to a destination memory, followed by updating the references (e.g., pointers) to the object. However, during the relocation, other threads may write to portions of the object that have already been relocated, and the updates may be lost when the references are updated to point to the destination memory. The object relocation may therefore mark the words of the object during relocation with a relocation value to indicate transfer to the destination memory without locking the threads. The threads may be configured to check the value the source memory during object access, and to access the corresponding word of the destination memory if the source memory word comprises the relocation value. While the probability of a large (e.g., 64-bit) relocation value appearing in the object is small, safety measures are provided to detect and mitigate conflicts.

Abstract: Described is a technology by which a real-time data relocating mechanism is provided for multiprocessing environments, including supporting lock-free programs that run in parallel. The relocating mechanism moves an object by using a status field related to the data field, possibly in an interim (wide) object space, which is then copied to a to-space object. The status information for each data field of the original object contains information indicating where a current version of the data for each field is present, that is, in the original, wide or to-space object. In one example, a handshake mechanism of a garbage collector establishes preparation and copy phases between the mechanism and other threads that determine where memory accesses occur. Also described is support for program thread compare-and-swap (CAS) operations and/or multi-word atomic operations.

Abstract: Described herein are one or more implementations that separate kernel interfaces functions into those that act on kernel objects owned by a process and accessed exclusively by that process—described herein as local kernel objects—from access to kernel objects owned by a process and accessible by other active processes.

Abstract: Described is a technology by which a real-time data relocating mechanism is provided for multiprocessing environments, including supporting lock-free programs that run in parallel. The relocating mechanism moves an object by using a status field related to the data field, possibly in an interim (wide) object space, which is then copied to a to-space object. The status information for each data field of the original object contains information indicating where a current version of the data for each field is present, that is, in the original, wide or to-space object. In one example, a handshake mechanism of a garbage collector establishes preparation and copy phases between the mechanism and other threads that determine where memory accesses occur. Also described is support for program thread compare-and-swap (CAS) operations and/or multi-word atomic operations.

Abstract: Described is a technology by which a real-time data relocating mechanism is provided for multiprocessing environments, including supporting lock-free programs that run in parallel. The relocating mechanism moves an object by using a status field related to the data field, possibly in an interim (wide) object space, which is then copied to a to-space object. The status information for each data field of the original object contains information indicating where a current version of the data for each field is present, that is, in the original, wide or to-space object. In one example, a handshake mechanism of a garbage collector establishes preparation and copy phases between the mechanism and other threads that determine where memory accesses occur. Also described is support for program thread compare-and-swap (CAS) operations and/or multi-word atomic operations.

Abstract: Concurrent, incremental, and lock-free stack scanning for garbage collectors is disclosed. This method uses a summary table and return barriers to allow high responsiveness. The method also supports programs that employ fine-synchronization to avoid locks, imposes negligible overhead on program execution, can be used with existing concurrent collectors, and supports the special in-stack references existing in languages such as C#.

Abstract: Existing methods for returning program state to a previous state are often too heavy weight. Often these methods attempt to guarantee a series of properties to a programmer across a distributed environment or multiple threads. Instead, a program state reversion mechanism provides a light weight and efficient runtime solution for general purpose programming languages. For example, a series of program statements (e.g., methods, instructions, etc.) are indicated by a programmer in a state reversion language construct, such as a TryAll block. If an exception is thrown anywhere from within the TryAll block, the program is reverted to the pre-TryAll block state.

Abstract: Object relocation often involves a multi-word copy of the object from a source memory to a destination memory, followed by updating the references (e.g., pointers) to the object. However, during the relocation, other threads may write to portions of the object that have already been relocated, and the updates may be lost when the references are updated to point to the destination memory. The object relocation may therefore mark the words of the object during relocation with a relocation value to indicate transfer to the destination memory without locking the threads. The threads may be configured to check the value the source memory during object access, and to access the corresponding word of the destination memory if the source memory word comprises the relocation value. While the probability of a large (e.g., 64-bit) relocation value appearing in the object is small, safety measures are provided to detect and mitigate conflicts.

Abstract: Object relocation often involves a multi-word copy of the object from a source address to a destination address, followed by updating the references (e.g., pointers) to the object. However, during the relocation, other threads may write to portions of the object that have already been relocated, and the updates may be lost when the references are updated to point to the destination address. A non-blocking relocation technique may be implemented to permit threads to write to the object during the relocation, wherein the memory accesses are monitored for a write to the object. If a write is detected during the relocation, the relocation fails and the memory at the destination address is deallocated; but if no write is detected, the relocation succeeds and the references are updated to point to the destination address. Refinements of this technique may be implemented to reduce other synchronization issues.

Abstract: Mechanism that employs code cloning and specialized code execution for barriers to minimize runtime overhead. This is facilitated by duplicating code and inserting specializations of the barriers in the code copies. The mechanism is effective for garbage collection when the garbage collection executes through different phases, and the barrier behavior and overheads depend on these phases. The duplicated and specialized code enables the program to run efficiently by reducing the dynamic count of a phase check when the phase is well-known and phase checks can be avoided.

Abstract: Described is a technology by which a real-time data relocating mechanism is provided for multiprocessing environments, including supporting lock-free programs that run in parallel. The relocating mechanism moves an object by using a status field related to the data field, possibly in an interim (wide) object space, which is then copied to a to-space object. The status information for each data field of the original object contains information indicating where a current version of the data for each field is present, that is, in the original, wide or to-space object. In one example, a handshake mechanism of a garbage collector establishes preparation and copy phases between the mechanism and other threads that determine where memory accesses occur. Also described is support for program thread compare-and-swap (CAS) operations and/or multi-word atomic operations.

Abstract: An object-oriented program is modified to create objects within specified regions, allowing memory de-allocation to take place for entire regions at once. The contents and associations between the regions are described by one or more shape graphs, which are created from an analysis of the program code. The region association metadata stored by the shape graphs allows the region-based memory management to take place while requiring no more than one region to be passed to methods for each object passed.

Abstract: Described herein are one or more implementations that separate kernel interfaces functions into those that act on kernel objects owned by a process and accessed exclusively by that process—described herein as local kernel objects—from access to kernel objects owned by a process and accessible_by other active processes.

Abstract: An object-oriented program is modified to create objects within specified regions, allowing memory de-allocation to take place for entire regions at once. The contents and associations between the regions are described by one or more shape graphs, which are created from an analysis of the program code. The region association metadata stored by the shape graphs allows the region-based memory management to take place while requiring no more than one region to be passed to methods for each object passed.

Abstract: Described herein are one or more implementations for describing and/or addressing the configuration requirements of applications, extensions, device drivers, and other components of a software system.

Abstract: Described herein are one or more implementations of an operating system that provides for statically verifiable inter-process communication between isolated processes. Also, described herein are one or more implementations of programming tools that facilitate the development of statically verifiable isolated processes having inter-process communication.

Abstract: Thread-specific heaps are employed in multithreaded programs to decrease garbage collection latency in such programs. Program data in a target program is analyzed to identify thread-specific data and shared data. Thread-specific data is identified on the basis that the thread-specific data is determined to be reachable only from a single program thread of the target program. Each program thread can be associated with an individual thread-specific heap. Shared data is identified on the basis that the shared data is potentially reachable from a plurality of program threads of the target program. An exemplary method of identifying such data is referred to as a thread escape analysis. Garbage collection of such heaps may be performed independently or with minimal synchronization. Remembered sets may also be used to increase the independence of collection of individual heaps and to decrease garbage collection latency.