Microsoft Technology Licensing, LLC

David Charles Wrighton

Mircea Trofin

Michal Strehovsky

Fadi M Hanna

John Lawrence Hamby

Atsushi Kanamori

Rudi Martin

Patrick Henri Dussud

Jan Kotas

Morgan Asher Brown

Stephen Harris Toub

Turgut Isik

Fatma Didem Gokbulut

Robert Yung-Yi Fu

Seth Mitchell Demsey

Christopher W Lorton

Michael Goldberg Boilen

Scott D Mosier

Robert Sadao Unoki

Ian Michael Bearman

Katrina Schaeffer

Jamie A De Guerre

Yi Zhang

Mads Torgersen

David Mitford Gillies

Peter F Sollich

Jared Porter Parsons

Peter Franz Valentin Sollich

Mei-Chin Tsai

Julien Couvreur

David Adam Hartglass

Michal Strehovský

Shah Mohammad Faizur Rahman

Nathan Herring

Hongtao Yu

Erdembilegt Janchivdorj

Anton Lapounov

Tomás Rylek

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.

Runtime support for role types that extend underlying types

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.

Embedding code from modules across versioning boundaries

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.

Thread-local return structure for asynchronous state machine

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.

Representing asynchronous state machine in intermediate code

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).

Controlling runtime access to application program interfaces

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.

Compatible dictionary layout

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.

Differentiated static analysis for dynamic code optimization

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. Degrees may enable or disable types, instance constructors, property setters, property getters, fields, or all type members. Directives may be composed.

Hierarchical directives-based management of runtime behaviors

An instance of universally shared generic code is generated. A runtime parameter enables the size of a stack frame on which local data can be stored to be determined. Dynamically sized locals can be stored on a stack enabling precise garbage collection reporting. One frame of the stack is allocated for each code segment to simplify GC reporting. A reporting region in the frame memory region comprises a count of locals and a location at which the local is found in the stack.

Dynamically sized locals with precise garbage collection reporting

Multiple different type hierarchies can communicate in a high performance and seamless manner by sharing a GC and interface dispatch logic. A runtime environment can support multiple independent type hierarchies, each type hierarchy defined by the module which defines the root of a type graph and some other helper functionality. Code that uses the dispatch logic has to follow certain rules in order to maintain GC and type safety. Different types in disjoint type graphs can behave as if they were one type for cross type graph communication purposes.

Seamless high performance interoperability between different type graphs that share a garbage collector

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.

Supporting dynamic behavior in statically compiled programs

Growing community of inventors

Redmond, WA, United States of America

David Charles Wrighton