Abstract: A computing system and method for determining if a first software component that has shipped separately from a second software component has been updated. An inline expansion process copies a first method of the first software component into a first method of a second software component is performed so that the copied first method is executable when the second method of the second software component is executed. The first method from the first software component is copied into metadata that is attached to the first method of the second software component. The copy of the first method in the metadata is used to validate that the first method in the first software component has not been updated.

Abstract: Utilizing role types that extend underlying types. Within a program definition, a computer system identifies a statement assigning an object of an underlying type to a role type that extends the underlying type. The underlying type implements a first interface, and the role type implements a second interface. Based on the role type extending the underlying type, the computer system assigns the object of the underlying type to the role type. Based on assigning the object of the underlying type to the role type, the role type is usable to interact with the object of the underlying type using both the first interface and the second interface.

Abstract: Reuse of a thread-local return data structure to prevent a return data structure from being allocated every time asynchronous functions return. The system returns thread operation from the asynchronous function back to the caller function in a manner that the return data structure can be reused for future asynchronous function returns within that same thread. To do so, the system first accesses data that was generated by the asynchronous function in response to the caller function placing the function call to the asynchronous function. To determine if reuse is appropriate, the system determines that the caller function will use the return data structure as populated only once. If so, the system populates the reusable thread-local return data structure and returns that data structure to the caller.

Abstract: Representing asynchronous functionality in intermediate code, and then having the runtime compiler, rather than the source code language compiler, declare the corresponding asynchronous state machine. This allows the size of the intermediate code to be smaller thereby facilitating more efficient delivery of the code to end users. Furthermore, the runtime compiler can now use its optimization capability to optimize performance of the asynchronous functionality specific to the actual environment in which the asynchronous work will operate.

Abstract: Reuse of a thread-local return data structure to prevent a return data structure from being allocated every time asynchronous functions return. The system returns thread operation from the asynchronous function back to the caller function in a manner that the return data structure can be reused for future asynchronous function returns within that same thread. To do so, the system first accesses data that was generated by the asynchronous function in response to the caller function placing the function call to the asynchronous function. To determine if reuse is appropriate, the system determines that the caller function will use the return data structure as populated only once. If so, the system populates the reusable thread-local return data structure and returns that data structure to the caller.

Abstract: Representing asynchronous functionality in intermediate code, and then having the runtime compiler, rather than the source code language compiler, declare the corresponding asynchronous state machine. This allows the size of the intermediate code to be smaller thereby facilitating more efficient delivery of the code to end users. Furthermore, the runtime compiler can now use its optimization capability to optimize performance of the asynchronous functionality specific to the actual environment in which the asynchronous work will operate.

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: Compatibility can be maintained when program code and pre-computed data associated with the program code are distributed in separate modules by using a data structure of key/value pairs comprising a dictionary. The dictionary can include a fixed part, a floating part and a version number. The version number in the dictionary can be used to determine if a dictionary for the program is current or outdated by comparing the dictionary version number and the version number associated with a dictionary layout in the current shared library. The dictionary can be rebuilt dynamically if the version number of the dictionary does not match the version number of the dictionary layout in the current shared library. The version number of the dictionary can be updated to the version associated with the layout version and the version pointer in the dictionary can be updated to point to the updated version number.

Abstract: A mechanism for generating optimized native code for a program having dynamic behavior uses a static analysis of the program to predict the likelihood that different elements of the program are likely to be used when the program executes. The static analysis is performed prior to execution of the program and marks certain elements of the program with confidence indicators that classify the elements with either a high level of confidence or a low level of confidence. The confidence indicators are then used by an ahead-of-time native compiler to generate native code and to optimize the code for faster execution and/or a smaller-sized native code.

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: Support for dynamic behavior is specified while reducing reliance on JIT compilation and large runtimes; semantic characteristics are selectively attached to types and type members outside source code. A directives document contains human-readable directives in a parsable format for submission to an innovative compiler. The directives specify whether a type T or type member M is required, optional, or prohibited in a runtime environment. Some reference an application, library, assembly, or namespace group, and others reference group components: type, type instantiation, method, method instantiation, field, property, or event. Some directives force a generic instantiation. Some directives indirectly reference a type through a parameter, type parameter, or generic directive. Some directives reference degrees to manage runtime activation of type instances, runtime introspection over types, reflection, and/or runtime or static serialization.

Abstract: A mechanism for generating optimized native code for a program having dynamic behavior uses a static analysis of the program to predict the likelihood that different elements of the program are likely to be used when the program executes. The static analysis is performed prior to execution of the program and marks certain elements of the program with confidence indicators that classify the elements with either a high level of confidence or a low level of confidence. The confidence indicators are then used by an ahead-of-time native compiler to generate native code and to optimize the code for faster execution and/or a smaller-sized native code.

Abstract: Compatibility can be maintained when program code and pre-computed data associated with the program code are distributed in separate modules by using a data structure of key/value pairs comprising a dictionary. The dictionary can include a fixed part, a floating part and a version number. The version number in the dictionary can be used to determine if a dictionary for the program is current or outdated by comparing the dictionary version number and the version number associated with a dictionary layout in the current shared library. The dictionary can be rebuilt dynamically if the version number of the dictionary does not match the version number of the dictionary layout in the current shared library. The version number of the dictionary can be updated to the version associated with the layout version and the version pointer in the dictionary can be updated to point to the updated version number.

Abstract: Support for dynamic behavior is provided during static compilation while reducing reliance on JIT compilation and large runtimes. A mapping is created between metadata and native code runtime artifacts, such as between type definition metadata and a runtime type description, or between method definition metadata, a runtime type description, and a native code method location, or field definition metadata, a runtime type description, and a field location. A mapping between runtime artifacts may also be created. Some compilation results include trampoline code to support a reflection invocation of an artifact in the reduced runtime support environment, for virtual method calls, call-time bounds checking, calling convention conversion, or compiler-intrinsic methods. Some results support runtime diagnostics by including certain metadata even when full dynamic behavior is not supported.

Abstract: The present invention extends to methods, systems, and computer program products for controlling runtime access to application programming interfaces Embodiments of the invention allow library developers to more precisely and easily control which of their libraries' APIs can be called dynamically. Thus, their servicing and versioning burden can be more appropriately controlled. Further, application developers can control which such APIs to further exclude from dynamic calling scenarios, to minimize the runtime support overhead (e.g., preventing generation of metadata).

Abstract: Support for dynamic behavior is specified while reducing reliance on JIT compilation and large runtimes; semantic characteristics are selectively attached to types and type members outside source code. A directives document contains human-readable directives in a parsable format for submission to an innovative compiler. The directives specify whether a type T or type member M is required, optional, or prohibited in a runtime environment. Some reference an application, library, assembly, or namespace group, and others reference group components: type, type instantiation, method, method instantiation, field, property, or event. Some directives force a generic instantiation. Some directives indirectly reference a type through a parameter, type parameter, or generic directive. Some directives reference degrees to manage runtime activation of type instances, runtime introspection over types, reflection, and/or runtime or static serialization.

Abstract: Support for dynamic behavior is specified while reducing reliance on JIT compilation and large runtimes; semantic characteristics are selectively attached to types and type members outside source code. A directives document contains human-readable directives in a parsable format for submission to an innovative compiler. The directives specify whether a type T or type member M is required, optional, or prohibited in a runtime environment. Some reference an application, library, assembly, or namespace group, and others reference group components: type, type instantiation, method, method instantiation, field, property, or event. Some directives force a generic instantiation. Some directives indirectly reference a type through a parameter, type parameter, or generic directive. Some directives reference degrees to manage runtime activation of type instances, runtime introspection over types, reflection, and/or runtime or static serialization.

Abstract: Support for dynamic behavior is specified while reducing reliance on JIT compilation and large runtimes; semantic characteristics are selectively attached to types and type members outside source code. A directives document contains human-readable directives in a parsable format for submission to an innovative compiler. The directives specify whether a type T or type member M is required, optional, or prohibited in a runtime environment. Some reference an application, library, assembly, or namespace group, and others reference group components: type, type instantiation, method, method instantiation, field, property, or event. Some directives force a generic instantiation. Some directives indirectly reference a type through a parameter, type parameter, or generic directive. Some directives reference degrees to manage runtime activation of type instances, runtime introspection over types, reflection, and/or runtime or static serialization.

Abstract: Support for dynamic behavior is specified while reducing reliance on JIT compilation and large runtimes; semantic characteristics are selectively attached to types and type members outside source code. A directives document contains human-readable directives in a parsable format for submission to an innovative compiler. The directives specify whether a type T or type member M is required, optional, or prohibited in a runtime environment. Some reference an application, library, assembly, or namespace group, and others reference group components: type, type instantiation, method, method instantiation, field, property, or event. Some directives force a generic instantiation. Some directives indirectly reference a type through a parameter, type parameter, or generic directive. Some directives reference degrees to manage runtime activation of type instances, runtime introspection over types, reflection, and/or runtime or static serialization.

Abstract: Support for dynamic behavior is provided during static compilation while reducing reliance on JIT compilation and large runtimes. A mapping is created between metadata and native code runtime artifacts, such as between type definition metadata and a runtime type description, or between method definition metadata, a runtime type description, and a native code method location, or field definition metadata, a runtime type description, and a field location. A mapping between runtime artifacts may also be created. Some compilation results include trampoline code to support a reflection invocation of an artifact in the reduced runtime support environment, for virtual method calls, call-time bounds checking, calling convention conversion, or compiler-intrinsic methods. Some results support runtime diagnostics by including certain metadata even when full dynamic behavior is not supported.