Abstract: Deployment and execution of a service in a multiple datacenter environment may be facilitated using datacenter execution templates. Developers, business managers, and other interested parties may select and/or modify a declarative execution template embodying multiple factors. The execution template may then be used to generate an execution plan, which is then executed by datacenters which run the service. The execution template may be optimized after deployment of the service, allowing for ongoing adjustment in response to changing business, regulatory, and operational factors.

Abstract: Software program robustness is improved by successfully masking memory safety errors in the software program. For instance, at least some memory safety errors in a software program can be masked by using a runtime memory manager that approximates the semantics of an infinite heap memory manager. In one example, an approximation of an infinite heap memory manager is implemented by configuring a parameterized memory manager with parameter values such as padding to be added to each allocation on the heap and the amount of deferment before executing a call to free memory on the heap. Ideal configurations balance expected robustness with costs such as added memory and processing time. Ideal configurations can be identified through systematic search of a coordinate space of selected parameters. Ideal configurations can also be identified by statistically correlating success/failure data collected from execution of deployed instances of the software program to the configuration of the memory managers used therein.

Abstract: A monitoring system may analyze system memory to determine a vulnerability statistic by identifying potential sleds within the memory, and creating a statistic that is a ratio of the amount of potential sleds per the total memory. In some cases, the statistic may be based on the number of instructions or bytes consumed by the sleds. The potential sleds may be determined by several different mechanisms, including abstract payload execution, polymorphic sled detection, sled surface area calculation, and other mechanisms. The monitoring system may be a multi-threaded operation that continually monitors system memory and analyzes recently changed objects in memory. When the vulnerability statistic rises above a certain level, the system may alert a user or administrator to a high vulnerability condition.

Abstract: Detecting and/or tolerating races. Races occur due to malicious threads not respecting software locks. A method of detecting and/or correcting races includes making local copie(s) and reference copie(s) of shared data. Any read and write operations performed by a safe thread are caused to be performed on the local copie(s) during a critical section. The critical section defines a time frame which a variable lock is placed on shared data. Any read and write operations performed by malicious threads are allowed to be performed on the shared data during the critical section. The shared data, the local copie(s), and the reference copie(s) are compared to determine that a race has been detected. An indication can be output that a race has occurred or the race can be corrected.

Abstract: Typical computer programs may incur costly memory errors that result in corrupted data. A new memory model is presented wherein it may be determined that certain data is critical and critical data may be stored and protected during computer application execution. Critical Memory allows that data determined to be critical may be stored and retrieved using functions enabled to increase the reliability of the data. Functions are presented enabling allocation of redundant computer memory; functions are presented enabling consistently writing critical data to redundant locations; and functions are presented enabling reading critical data while ensuring that the data read is consistent with the most recent write of critical data and enabled to repair inconsistent data. The memory model and functions presented are designed to be compatible with existing third-party libraries.

Abstract: Typical computer programs may incur costly memory errors that result in corrupted data. A new memory model is presented wherein it may be determined that certain data is critical and critical data may be stored and protected during computer application execution. Critical Memory allows that data determined to be critical may be stored and retrieved using functions enabled to increase the reliability of the data. Critical Memory presents a memory model where a subset of memory designated as critical memory may be used to store a subset of data deemed critical data. Probabilistic guarantees of data value consistency are provided by the employment of the new memory model. The memory model and functions presented are compatible with existing third-party libraries such that third-party libraries may be compatibly called from processes using critical memory.

Abstract: A programming-language construct called a program history, and a method, system, apparatus, and data structure for translating computer source code that contains the program history construct. A program history captures data regarding the state of the program as it executes and makes this data available to functions called history operators, which operate on the data. The source code contains a history operand, an instance of the history operand, and the history operator. The presence of the history operand directs a translator to cause history data to be saved regarding the sequence of data that is associated with the operand instance as the program executes. The presence of the history operator directs the translator to cause a function to be performed that saves history data. In this way, the programmer is freed from writing tedious and error-prone bookkeeping code that declares variables and saves history data into those declared variables.

Abstract: Programming language constructs called pronouns and referents, and a method, system, and apparatus for translating computer source code that contains the pronouns and referents. A referent is any semantic or syntactic construct in the source code (e.g., a statement, a portion of a statement, an expression, or a value) to which a pronoun refers. A pronoun is a programming-language defined source-code symbol or a sequence of symbols that refers to the referent. As a result, pronouns eliminate the need to define new names or macros for repeated program segments. When a translator encounters the pronoun in the source code, the translator searches the source code for the referent and substitutes the referent for the pronoun. Thus, by using pronouns and referents, the programmer can write programs faster and easier and eliminate program redundancy without losing readability.

Abstract: Programming language constructs called pronouns and referents, and a method, system, and apparatus for translating computer source code that contains the pronouns and referents. A referent is any semantic or syntactic construct in the source code (e.g., a statement, a portion of a statement, an expression, or a value) to which a pronoun refers. A pronoun is a programming-language defined source-code symbol or a sequence of symbols that refers to the referent. As a result, pronouns eliminate the need to define new names or macros for repeated program segments. When a translator encounters the pronoun in the source code, the translator searches the source code for the referent and substitutes the referent for the pronoun. Thus, by using pronouns and referents, the programmer can write programs faster and easier and eliminate program redundancy without losing readability.

Abstract: A programming-language construct called a program history, and a method, system, apparatus, and data structure for translating computer source code that contains the program history construct. A program history captures data regarding the state of the program as it executes and makes this data available to functions called history operators, which operate on the data. The source code contains a history operand, an instance of the history operand, and the history operator. The presence of the history operand directs a translator to cause history data to be saved regarding the sequence of data that is associated with the operand instance as the program executes. The presence of the history operator directs the translator to cause a function to be performed that saves history data. In this way, the programmer is freed from writing tedious and error-prone bookkeeping code that declares variables and saves history data into those declared variables.